Date: Thu, 15 Sep 2005 17:19:05 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding and net.inet.ip.fastforwarding Message-ID: <20050915171617.D75005@fledge.watson.org> In-Reply-To: <4321BD3D.66417FA6@freebsd.org> References: <20050908221115.038c3abd.lists@yazzy.org> <004701c5b4df$9207d260$1200a8c0@gsicomp.on.ca> <4320EDDF.6090303@errno.com> <20050909054110.08pqjx9bi884c0sg@mail.bafirst.com> <4321BA08.9060500@errno.com> <4321BD3D.66417FA6@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Sep 2005, Andre Oppermann wrote: >> 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?). > > When activated on a router it gives a very nice speed boost. Process > completion pays off very well here. It has got a lot of testing at > various ISP's on their production routers. For hosts it doesn't really > hurt but is totally pointless. In measurements a couple of years ago, I demonstrated to myself that on several interesting pieces of hardware, running with net.isr.enable=1 resulted in lower latency packet forwarding and processing on 5.x (at the time) than 4.x (at the time). I've not re-measured with recent 7.x/6.x or 4.x on recent hardware. Over the last couple of years, we've shaken out a number of important bugs in local network stack code that tripped up with net.isr.enable, so we're reaching the point where I might start encouraging people to work with it more actively for local (as well as routed) paths. There are still open questions about what models make the most sense, though -- run to completion has some nice latency properties, and also increases the opportunities for parallelism in the network stack. On the other hand, it increases the load born by ithreads, so if your ithread was already maxing out available CPU, you would decrease the amount of work it could do, and on UP it can result in more context switches if you have several active interfaces running out of different ithreads. Many of these questions are the same as the ones we'll be talking about for next generation polling support at the developer summit this fall, so it would make sense to talk about them at the same time. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050915171617.D75005>