Date: Sun, 21 Feb 1999 02:37:07 -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: <199902211037.CAA12487@implode.root.com> In-Reply-To: Your message of "Sat, 20 Feb 1999 23:58:02 EST." <199902210458.XAA12913@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
The jumbo frames are only useful if you also have VLAN support, which we don't have currently. We also need support for large mbuf clusters; this probably should be done by implementing external-buffer management functions ala sendfile's sf_bufs. For now I think the sensible thing to do is use standard ethernet frames and deal with jumbo's when the infrustructure is there to support them. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project >Recently I obtained the programming info for the Alteon Tigon gigabit >ethernet chip (http://www.alteon.com/support/openkits). This is the >chip used in the Alteon AceNIC, the 3Com 3c985 and the Netgear GA620 >ethernet boards. The Tigon supports jumbo ethernet frames, which are >9014 bytes in size (14 bytes header, 9000 bytes data). > >The use of jumbo frames is optional, but I'd like to support them. >The question is, what's the best mbuf allocation strategy for receiving >frames this size? The scheme I normally use is to allocate a single mbuf >with MGETHDR and then attach an mbuf cluster to that with MCLGET. >An mbuf cluster buffer is 2K, which is enough to hold a complete >ethernet frame up to the maximum frame size (1514). The address >of the cluster buffer is passed to the ethernet controller, so that >it can DMA received packets directly into the mbuf which can then >be passed directly to ether_input() without any buffer copying. >(And avoiding buffer copying at gigabit speeds is highly desireable.) > >I would like to use something similar for the jumbo frames, but >I'm not entirely sure how to pre-allocate the buffers. I thought >about allocating external mbuf storage independent of the cluster >buffer pool, but 9K is larger than the page size, so I'd need to use >contigmalloc() in order to be sure of getting contiguous pages (the >chip will be DMAing into the buffers and it has no knowledge of the >kernel's virtual page mappings). Using contigmalloc() can easily >fail as memory becomes fragmented however. > >The alternative is to allocate an mbuf cluster chain, breaking up >the packet into 2K chunks. I think this involves one MGETHDR(), >four MGET()s and five MCLGETS(). It would be nice to find a >quick and dirty way to allocate the chain, but I don't see one >offhand. > >It's very possible that there's a more elegant way to handle this, >but I haven't been able to think of any. If anyone has any suggesstions, >I'd love to hear them. > >-Bill > >-- >============================================================================= >-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu >Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research >Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City >============================================================================= > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" >============================================================================= > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message 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?199902211037.CAA12487>