Date: Fri, 19 Oct 2012 14:02:46 +0200 From: Andre Oppermann <oppermann@networx.ch> To: "Andrey V. Elsukov" <ae@FreeBSD.org> Cc: ipfw@freebsd.org, net@freebsd.org Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time Message-ID: <50814166.1000602@networx.ch> In-Reply-To: <508138A4.5030901@FreeBSD.org> References: <508138A4.5030901@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19.10.2012 13:25, Andrey V. Elsukov wrote: > Hi All, > > Many years ago i have already proposed this feature, but at that time > several people were against, because as they said, it could affect > performance. Now, when we have high speed network adapters, SMP kernel > and network stack, several locks acquired in the path of each packet, > and i have an ability to test this in the lab. > > So, i prepared the patch, that removes IPFIREWALL_FORWARD option from > the kernel and makes this functionality always build-in, but it is > turned off by default and can be enabled via the sysctl(8) variable > net.pfil.forward=1. > > http://people.freebsd.org/~ae/pfil_forward.diff > > Also we have done some tests with the ixia traffic generator connected > via 10G network adapter. Tests have show that there is no visible > difference, and there is no visible performance degradation. > > Any objections? No objection as such. However I don't entirely agree with the naming of pfil_forward. The functionality is specific to IPFW and TCP, it's doing transparent interjected termination of tcp connections on the local host while keeping the original IP addresses and port numbers visible in netstat output. So it's a feature of IPFW/IP and should be fitted in there for sysctl name and .h files instead of pfil. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50814166.1000602>