[RFC] Enabling IPFIREWALL_FORWARD in run-time

[Ian Smith]

On Fri, 19 Oct 2012 15:25:24 +0400, 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?

Looks great.  I'll no longer have to tell people on questions@ that 
using ipfw fwd is the only reason left not to just load the module.

Taking the code on trust, only to comment on the documentation:

ipfw.8:
======= 
 To enable
 .Cm fwd
-a custom kernel needs to be compiled with the option
-.Cd "options IPFIREWALL_FORWARD" .
+the
+.Xr sysctl 8
+variable
+.Va net.pfil.forward
+should be set to 1.

NOTES:
=======
-# IPFIREWALL_FORWARD enables changing of the packet destination either
-# to do some sort of policy routing or transparent proxying.  Used by
-# ``ipfw forward''. All  redirections apply to locally generated
-# packets too.  Because of this great care is required when
-# crafting the ruleset.

ipfw(8) could perhaps incorporate that description (and warning) from 
NOTES in the entry under SYSCTLS where net.pfil.forward (or whatever :) 
would be expected to be described, apart from sysctl -d ?

cheers, Ian

 > WBR, Andrey V. Elsukov