Date: Fri, 09 Sep 2005 09:36:24 -0700 From: Sam Leffler <sam@errno.com> To: eculp@bafirst.com Cc: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding and net.inet.ip.fastforwarding Message-ID: <4321BA08.9060500@errno.com> In-Reply-To: <20050909054110.08pqjx9bi884c0sg@mail.bafirst.com> References: <20050908221115.038c3abd.lists@yazzy.org> <004701c5b4df$9207d260$1200a8c0@gsicomp.on.ca> <4320EDDF.6090303@errno.com> <20050909054110.08pqjx9bi884c0sg@mail.bafirst.com>
index | next in thread | previous in thread | raw e-mail
eculp@bafirst.com wrote: > Quoting Sam Leffler <sam@errno.com>: > >> Matt Emmerton wrote: >> >>>> Hi guys. >>>> >>>> What's the difference between net.inet.ip.forwarding and >>> >>> >>> net.inet.ip.fastforwarding ? >>> >>>> What's the role of net.inet.ip.fastforwarding ? >>> >>> >>> >>>> From inet(4): >>> >>> >>> IPCTL_FORWARDING (ip.forwarding) Boolean: enable/disable >>> forwarding >>> of IP packets. Defaults to off. >>> >>> IPCTL_FASTFORWARDING (ip.fastforwarding) Boolean: >>> enable/disable the >>> use >>> of fast IP forwarding code. Defaults to off. >>> When >>> fast forwarding is enabled, IP packets are >>> for- >>> warded directly to the appropriate network >>> inter- >>> face with a minimal validity checking, which >>> greatly improves the throughput. On the >>> other >>> hand, they bypass the standard procedures, >>> such >>> as >>> IP option processing and ipfirewall(4) >>> checking. >>> It is not guaranteed that every packet >>> will be >>> fast-forwarded. >>> >> >> This quote is out of date; on current fastforwarding is purely an >> optimization path--if the packet requires features not supported by >> the fast path then it's processed normally. > > > Maybe I should have another ristreto before asking this, but based on > what I understand from this thread and speaking of current 7.0: > > a. I would set both in sysctl.conf > net.inet.ip.forwarding=1 > net.inet.ip.fastforwarding=1 > b. There would be no "down side" in current 7.0 > > Is this more or less correct? If so, will this posibly be the case in > the 6.0 release also or only in current? 6.0 and 7.x share the same code so the settings are identical. As to downside you pay a penalty if the fastforwarding code has to hand the packet back to the "slow path". There may also be side effects from the run-to-completion model it uses. You should test to decide if the feature is worth enabling for your environment. I'm not sure it's had much testing (Andre?). Samhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4321BA08.9060500>