svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw

[Andre Oppermann]

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.
>