Date: Fri, 26 Oct 2012 15:30:05 +0200 From: Andre Oppermann <andre@freebsd.org> To: "Andrey V. Elsukov" <ae@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, src-committers@FreeBSD.org Subject: Re: svn commit: r242079 - in head: sbin/ipfw share/man/man4 sys/conf sys/net sys/netinet sys/netinet6 sys/netpfil/ipfw Message-ID: <508A905D.3080702@freebsd.org> In-Reply-To: <508A8F1A.7020902@freebsd.org> References: <201210250939.q9P9dF0q022970@svn.freebsd.org> <508960C2.6030003@freebsd.org> <508967E3.3070508@FreeBSD.org> <5089A13F.8080405@freebsd.org> <20121026112629.GC70741@FreeBSD.org> <508A7762.1040106@freebsd.org> <508A823A.30308@FreeBSD.org> <508A8F1A.7020902@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?508A905D.3080702>