From owner-freebsd-ipfw@FreeBSD.ORG Sun May 24 08:24:52 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4B21BE6; Sun, 24 May 2015 08:24:52 +0000 (UTC) Received: from forward5h.mail.yandex.net (forward5h.mail.yandex.net [IPv6:2a02:6b8:0:f05::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 792C31257; Sun, 24 May 2015 08:24:52 +0000 (UTC) Received: from web15h.yandex.ru (web15h.yandex.ru [84.201.186.44]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 319DAD0117F; Sun, 24 May 2015 11:24:47 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web15h.yandex.ru (Yandex) with ESMTP id 44DBF5900CFB; Sun, 24 May 2015 11:24:46 +0300 (MSK) Received: by web15h.yandex.ru with HTTP; Sun, 24 May 2015 11:24:45 +0300 From: Alexander V. Chernikov Envelope-From: melifaro@ipfw.ru To: hiren panchasara , Jason Wolfe Cc: "freebsd-ipfw@freebsd.org" , Julian Elischer , Ian Smith In-Reply-To: <20150523005828.GL95600@strugglingcoder.info> References: <20150414210901.GA10620@strugglingcoder.info> <552F2F82.1060506@freebsd.org> <20150416164024.B93161@sola.nimnet.asn.au> <20150521194227.GF95600@strugglingcoder.info> <20150521210505.GH95600@strugglingcoder.info> <20150523005828.GL95600@strugglingcoder.info> Subject: Re: ipfw on just inbound and not outbound MIME-Version: 1.0 Message-Id: <242041432455885@web15h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 24 May 2015 11:24:45 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 08:24:52 -0000 23.05.2015, 03:58, "hiren panchasara" : > 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. 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) > > cheers, > Hiren From owner-freebsd-ipfw@FreeBSD.ORG Sun May 24 10:11:23 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 892857A1; Sun, 24 May 2015 10:11:23 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D93821D15; Sun, 24 May 2015 10:11:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t4OABC9K063696; Sun, 24 May 2015 20:11:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 24 May 2015 20:11:12 +1000 (EST) From: Ian Smith To: "Alexander V. Chernikov" cc: hiren panchasara , Jason Wolfe , "freebsd-ipfw@freebsd.org" , Julian Elischer Subject: Re: ipfw on just inbound and not outbound In-Reply-To: <242041432455885@web15h.yandex.ru> Message-ID: <20150524195454.H7173@sola.nimnet.asn.au> References: <20150414210901.GA10620@strugglingcoder.info> <552F2F82.1060506@freebsd.org> <20150416164024.B93161@sola.nimnet.asn.au> <20150521194227.GF95600@strugglingcoder.info> <20150521210505.GH95600@strugglingcoder.info> <20150523005828.GL95600@strugglingcoder.info> <242041432455885@web15h.yandex.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2015 10:11:23 -0000 On Sun, 24 May 2015 11:24:45 +0300, Alexander V. Chernikov wrote: > 23.05.2015, 03:58, "hiren panchasara" : > > 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)