Date: Sun, 21 Feb 1999 13:24:00 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: bright@cygnus.rush.net (Alfred Perlstein) Cc: hackers@freebsd.org Subject: Re: How to handle jumbo etherney frames Message-ID: <199902211824.NAA13983@skynet.ctr.columbia.edu> In-Reply-To: <Pine.BSF.3.96.990221062740.10060W-100000@cygnus.rush.net> from "Alfred Perlstein" at Feb 21, 99 06:30:44 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Alfred Perlstein had to walk into mine and say: > > > 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.) > > please excuse genrally cluelessness here, but why not have some sort of > flag to tell the driver how much space to pre-allocate? when done at > boot time, i thought that contiqalloc is ok to use. having a seperate > memory allocator is bad form, but for maximal performance it may be > nessesary. Because I want to avoid buffer copying. If I allocate a bunch of buffers for jumbo frames at boot time, then I can't hand them off to the upper protocol layers because then they'll get freed back to the OS and I'll eventually run out. I could just keep the 9K buffers to myself and use m_devget() to transfer the packet data from the contiguous buffer to an mbuf chain when a frame arrives, but that means copying. > I know DG is proposing using smaller buffers, but if you can can preallocate > and the performance tradeoff is worth the nasty code, woudn't it be worth > it in the long run? At 100Mbps on a really fast CPU, maybe. At 1000Mbps? I doubt it. -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?199902211824.NAA13983>