Date: Sat, 20 Feb 1999 23:58:02 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: hackers@freebsd.org Subject: How to handle jumbo etherney frames Message-ID: <199902210458.XAA12913@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902210458.XAA12913>