Date: Thu, 6 May 2004 00:57:50 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Gerrit Nagelhout <gnagelhout@sandvine.com> Cc: 'Robert Watson' <rwatson@freebsd.org> Subject: Re: 4.7 vs 5.2.1 SMP/UP bridging performance Message-ID: <20040506005750.A5666@xorpc.icir.org> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C85337021AB385@mail.sandvine.com>; from gnagelhout@sandvine.com on Wed, May 05, 2004 at 07:38:38PM -0400 References: <FE045D4D9F7AED4CBFF1B3B813C85337021AB385@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 05, 2004 at 07:38:38PM -0400, Gerrit Nagelhout wrote: > Robert Watson wrote: ... > > Getting polling and SMP to play nicely would be a very good thing, but > > isn't something I currently have the bandwidth to work on. > > Don't suppose we could interest you in that? :-) ... > I won't be able to work on that feature anytime soon, but if some > prototyping turns out to have good results, and the mutex cost issues > are worked out, it's quite likely that we'll try to implement it. The > original author of the polling code (Luigi?) may have some input on > this as well. ENOTIME at the moment, but surely i would like to figure out first some locking issues e.g. related to the clustering of packets to reduce the number of locking ops. The other issue is the partitioning of work -- no point in having multiple polling loops work on the same interface. Possibly we might try to restructure the processing in the network stack by using one processor/polling loop that quickly determines the tasks that need work and then posts the results so that other processors can grab one task each. Kind of a dataflow architecture, in a sense. In any case, I am really impressed by the numbers Gerrit achieved in the UP/4.7 case -- i never went above 800kpps though in my case i think i was limited by the PCI bus (64 bit, 100MHz) or possibly even the chipset cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040506005750.A5666>