From owner-freebsd-hackers Sun Feb 21 10:17:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id CAAAC11AC9 for ; Sun, 21 Feb 1999 10:17:12 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id NAA13983; Sun, 21 Feb 1999 13:24:01 -0500 From: Bill Paul Message-Id: <199902211824.NAA13983@skynet.ctr.columbia.edu> Subject: Re: How to handle jumbo etherney frames To: bright@cygnus.rush.net (Alfred Perlstein) Date: Sun, 21 Feb 1999 13:24:00 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: from "Alfred Perlstein" at Feb 21, 99 06:30:44 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2338 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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