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