Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 May 2015 20:11:12 +1000 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        "Alexander V. Chernikov" <melifaro@freebsd.org>
Cc:        hiren panchasara <hiren@strugglingcoder.info>, Jason Wolfe <nitroboost@gmail.com>, "freebsd-ipfw@freebsd.org" <freebsd-ipfw@freebsd.org>, Julian Elischer <julian@freebsd.org>
Subject:   Re: ipfw on just inbound and not outbound
Message-ID:  <20150524195454.H7173@sola.nimnet.asn.au>
In-Reply-To: <242041432455885@web15h.yandex.ru>
References:  <20150414210901.GA10620@strugglingcoder.info> <552F2F82.1060506@freebsd.org> <20150416164024.B93161@sola.nimnet.asn.au>  <CAAAm0r0uZbbW5mVRVsOE-ooqqTDngM9Z2dMpECihoGR9=Tn=Vg@mail.gmail.com>  <20150521194227.GF95600@strugglingcoder.info> <20150521210505.GH95600@strugglingcoder.info> <20150523005828.GL95600@strugglingcoder.info> <242041432455885@web15h.yandex.ru>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, 24 May 2015 11:24:45 +0300, Alexander V. Chernikov wrote:
 > 23.05.2015, 03:58, "hiren panchasara" <hiren@strugglingcoder.info>:
 > > On 05/21/15 at 02:05P, hiren panchasara wrote:
 > >>  On 05/21/15 at 12:42P, hiren panchasara wrote:
 > >>>  Getting back to this now to see if I can avoid ipfw on outgoing packets.
 > >>>
 > >>>  @@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf)
 > >>>          hook_func = (pf == AF_LINK) ? ipfw_check_frame : ipfw_check_packet;
 > >>>
 > >>>          (void) (onoff ? pfil_add_hook : pfil_remove_hook)
 > >>>  -           (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
 > >>>  +           (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh);
 > >>>
 > >>>          return 0;
 > >>>  }
 > >>>
 > >>>  Should this do the right thing? I'll report back once I test this patch.
 > >>  I am still seeing ipfw_chk() getting called in my iperf test. Now, if I
 > >>  also remove PFIL_IN, i.e if I do:
 > >>  -           (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
 > >>  +           (hook_func, NULL, PFIL_WAITOK, pfh);
 > >>
 > >>  I don't see ipfw_chk() getting triggered.
 > >>
 > >>  Somehow incoming traffic is affecting the outgoing traffic?
 > >
 > > It seems I screwed up something in testing and the following does seem to do the
 > > right thing:
 > >
 > > -           (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
 > > +           (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh);
 > >
 > > I confirmed this with pmcstat callgraphs that ipfw_chk() is not getting
 > > called in OUT direction.
 > >
 > > Any thoughts on this? Is this something that can be upstreamed with a
 > > sysctl knob if there is interest?

 > Unfortunately, I've missed most of the thread.
 > First of all, just calling ipfw hook should not be so costy - I can 
 > believe in 5% in 8/9/10, but the reason should be not ipfw, but 
 > rwlock which is used ti protect ruleset.
 > HEAD version should behave better (we observe something like 1% 
 > overhead on 10+mpps rate) since it uses rmlock.

That's certainly a big improvement.

 > Being able to attach/detach appropriate L3 hooks is really a good 
 > idea, however the better (but not easier way) would be to implement 
 > something like `pfilctl' utility which would be able to 
 > control/disable/reorder hooks on particular filtering points (pf 
 > before ipfw or vice versa). This stuff would also help to convert 
 > some of the current L2 processing code to pfil (like 
 > BPF,lagg,netgraph input hooks in eher_input)

Well ipfw already may be seeing L2 traffic via net.link.ether.ipfw; is 
that already separate from the L3 pfil hooks?  I haven't followed pfil.

The more generic way to link and order hooks sounds like a better idea 
than needing to mess with ipfw (or pf, or anything) to accomplish that.

cheers, Ian (FWIW)



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20150524195454.H7173>