Date: Wed, 3 Mar 2004 12:59:46 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Luigi Rizzo <rizzo@icir.org> Cc: freebsd-hackers@freebsd.org Subject: Re: em0, polling performance, P4 2.8ghz FSB 800mhz Message-ID: <16454.7442.840699.631259@grasshopper.cs.duke.edu> In-Reply-To: <20040303094524.A26257@xorpc.icir.org> References: <FE045D4D9F7AED4CBFF1B3B813C85337045D832C@mail.sandvine.com> <16453.62383.59435.72390@grasshopper.cs.duke.edu> <20040303094524.A26257@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo writes: > On Wed, Mar 03, 2004 at 10:03:11AM -0500, Andrew Gallatin wrote: <...> > > I'm trying to design a new ethernet API for a firmware-based nic, > > and I'm trying to convince a colleague that having separate > > receive rings for small and large frames is a really good thing. > > i am actually not very convinced either, unless you are telling me > that there is a way to preserve ordering. Or you'd be in trouble > when, on your busy link, there is a mismatch between user-level and > link-level block sizes. > > So, what is your design like, you want to pass the NIC buffers of > 2-3 different sizes and let the NIC choose from the most appropriate > pool depending on the incoming frame size, but still return > received frames in a single ring in arrival order ? Yes, exactly. This way you get to pass the stack small (<MHLEN) frames in mbufs, rather than clusters without doing something like copying them in the driver's rx interrupt handler. You can allocate tons of mbufs so that you can absorb the occasional burst (or spike in host latency) without being as bad of pig as you'd be if you allocated a huge number of clusters ;) You also get to set yourself up for zero-copy receive by splitting the headers into mbufs, and the payloads into jumbo clusters that can get page-flipped. But that's a lot trickier and not really in the scope of the initial implementation. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16454.7442.840699.631259>