Date: Fri, 5 Jul 2002 11:21:01 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: "Kenneth D. Merry" <ken@kdm.org>, net@FreeBSD.ORG Subject: Re: virtually contig jumbo mbufs (was Re: new zero copy sockets snapshot) Message-ID: <20020705112101.A566@unixdaemons.com> In-Reply-To: <15653.45342.299963.692216@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Jul 05, 2002 at 10:45:50AM -0400 References: <20020620114511.A22413@unixdaemons.com> <15634.534.696063.241224@grasshopper.cs.duke.edu> <20020620134723.A22954@unixdaemons.com> <15652.46870.463359.853754@grasshopper.cs.duke.edu> <20020705002056.A5365@unixdaemons.com> <15653.35919.24295.698563@grasshopper.cs.duke.edu> <20020705093435.A25047@unixdaemons.com> <15653.43437.658461.49860@grasshopper.cs.duke.edu> <20020705104247.A518@unixdaemons.com> <15653.45342.299963.692216@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 05, 2002 at 10:45:50AM -0400, Andrew Gallatin wrote: > > Bosko Milekic writes: > > > > On Fri, Jul 05, 2002 at 10:14:05AM -0400, Andrew Gallatin wrote: > > > I think this would be fine, But we'd need to know more about the > > > hardware limitations of the popular GiGE boards out there. We know > > > Tigon-II can handle 4 scatters, but are there any that can handle 3 > > > but not four? > > > > Why would you need 4? I can absolutely guarantee that a jumbo buf > > will not go over 3 pages (on i386, and 2 pages on alpha). > > > > Perhaps I misread your earlier message. I thought you wanted to be > free to align them on something other than a page boundary, so as to > not waste so much space. In that case you'd need 4 scatters on i386, > right? All I meant was that I wouldn't guarantee that the buffer _begins_ at a page boundary. However, it still should only span at most 3 pages on i386. Let's say for the sake of argument that we won't need more than 9212 bytes for a jumbo buffer. Let's make the buffer 4 bytes bigger so that we'll have space for a ref. counter for it too (how convenient), so we'll allocate buffers of 9212 + 4 = 9216 bytes. It's time to allocate from the map: I'll try to grab 9 pages for a total of 4 jumbo buffers each spanning at most 3 pages (this is i386). I'll start the first buffer at the beginning of the first page and it'll end ((9216 - 8192) = 1024) bytes into the third page. I'll then start the second jumbo buffer there and finish it 2048 bytes into 5th page. I would then start the 3rd jumbo buffer there and finish it 3072 bytes into the 7th page. The last jumbo buf would start there and finish at the end of the 9th page. If my calculations are correct, that means that each jumbo buffer would span exactly 3 pages, but only the first one in the grouping would begin at a page boundary. There is also minimum wastage here. Briefly: Assuming that size_of_buf >= 2 * PAGE_SIZE, this is the above: PAGE_SIZE % (size_of_buf - 2 * PAGE_SIZE) == 0 We pick size_of_buf as small as possible but enough to accomodate the MTU and, and if possible, the ref. counter. I think 9216 should be a good number. At the same time, we try to make: bufs_per_bucket = PAGE_SIZE (integer DIV) (size_of_buf - 2 * PAGE_SIZE) bufs_per_bucket fairly reasonable (i.e., not too big). In the above scenario, size_of_buf = 9216 and bufs_per_bucket = 4. Admittedly, the numbers above were cooked up, but I think that they're fairly reasonable. > Drew Cheers, -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020705112101.A566>