On 10/19/12 4:25 AM, 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?
The number of times I've been brought to a running production system
and asked "can you do (mumble)
to solve problem 'X' ?", and my answer has been "well we'll have to
recompile a
kernel to get IPFIREWALL_FORWARD, but then, yes"
to be met by "oh but we can't shutdown until XXX days from now due to
uptime constraints and rules."
is more than I can remember. (mostly back in Vicor days) but
in fact, right now I have a system where I want to do this but the
original source tree it was
built from has been lost so I need to actually rebuild the entire
system just to get it.
(It's an embedded system)
so yes please!
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
