On 26.10.2012 15:24, Andre Oppermann wrote:
On 26.10.2012 14:29, Andrey V. Elsukov wrote:
On 26.10.2012 15:43, Andre Oppermann wrote:
A> If you can show with your performance profiling that the sysctl
A> isn't even necessary, you could leave it completely away and have
A> pfil_forward enabled permanently. That would be even better for
A> everybody.
I'd prefer to have the sysctl. Benchmarking will definitely show
no regression, because in default case packets are tagless. But if
packets would carry 1 or 2 tags each, which don't actually belong
to PACKET_TAG_IPFORWARD, then processing would be pessimized.
With M_FASTFWD_OURS I used an overlay of the protocol specific M_PROTO[1-5]
mbuf flags. The same can be done with M_IPFORWARD. The ipfw code then
will not only add the m_tag but also set M_IPFORWARD flag. That way no
sysctl is required and the feature is always available. The overlay
definition is in ip_var.h.
It seems we have only one bit in the m_flags that can be used, so, maybe
we left it to some things that can appear in the future?
That's what the M_PROTO flags are for:
#define M_IPFW_FORWARD M_PROTO2 /* ip forwarding */
Actually looking at it technically this isn't forwarding but specifying
a different nexthop. Hence the #define and description should be more
like
#define M_IP_NEXTHOP M_PROTO2 /* explicit ip nexthop */
Of course the userspace ipfw feature naming and usage doesn't change.
But within the kernel it's really nexthop manipulation within the
forwarding path.
--
Andre
of course you have to do the same for ip6.
The M_PROTO[1-5] flags are only valid within a protocol layer. For
example they get cleared in ip_output() before the packet is handed
to layer 2.
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
