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)