Date: Sun, 21 Feb 1999 17:10:15 -0800 From: David Greenman <dg@root.com> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@freebsd.org Subject: Re: How to handle jumbo etherney frames Message-ID: <199902220110.RAA15394@implode.root.com> In-Reply-To: Your message of "Sun, 21 Feb 1999 14:03:30 EST." <199902211903.OAA14038@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>Programming the chip to use a single vlan tag wouldn't require that much >work. Whether to use a VLAN and/or which VLAN to use is a per destination thing, not a per host/interface thing, so I don't think a single VLAN would be very useful. >I'm not really inclined to just implement only standard frame support >and wait around for large mbuf cluster support to materialize since there's >no telling how long that could take. I think I may be stuck between a Then implement large mbuf support. :-) >This is important because the manual seems to claim that as far as the >jumbo ring is concerned, if you use normal descriptors, each descriptor >buffer will always contain one complete frame. In other words, each >descriptor must point to a contiguous buffer large enough to hold a >9K frame. If you want to use several non-contiguous buffers, then you >have to use the extended descriptor format, which only allows four buffers. >Since an mbuf cluster is only 2K, this isn't enough. > >The only way I can think of to get around this problem is to use an >mbuf with external storage consisting of a single 9K buffer. However, >since 9K is larger than the page size, I can't be assured of always >getting 9K of contiguous storage, so I need to engage in a little >subterfuge. > >What I'm thinking of doing is this: > >- Program the chip to use extended jumbo ring descriptors. >- Get an mbuf using MGETHDR(). >- malloc() a 9K buffer and attach it to the mbuf as external storage. >- Assign the start address of the 9K buffer to the first host address > pointer in the ring descriptor. >- Round the address up to a page boundary. >- Assign this page address to the second host address pointer in the > descriptor. >- Round up to the next page again. >- Assign that address to the third host address pointer. >- Set all the fragment lengths accordingly so we end up with a total > of 9K. > >Basically I'm doing page mapping for the chip. It's possible that I >might end up with contiguously allocated space in which case all of this >is a pessimization, but I can never know that without grovelling around >in the kernel page tables, and that would take a lot more work. > >Am I insane? Well, wait: that's a given. But does this scheme at >least sound reasonable? Using malloc for this is probably not a good idea since it wants to allocate power of two sizes, so you'd needlessly waste a whole page. This really needs a special allocator specifically designed to deal with the needs of large mbuf clusters. Again, I think using the external mbuf storage mechanism is the right way to glue this in. One other comment...when I was looking at this stuff I came to the conclusion that supporting the Tigon 1 was a waste of time since it appears to be obsolete. Support for just the Tigon 2 should simplify the driver. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902220110.RAA15394>