From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 14:47:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23AF5CB8; Mon, 12 Nov 2012 14:47:56 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 86EAB8FC18; Mon, 12 Nov 2012 14:47:54 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qACElrPn009623; Mon, 12 Nov 2012 07:47:53 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qACElnjg021331; Mon, 12 Nov 2012 07:47:49 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Memory reserves or lack thereof From: Ian Lepore To: Andre Oppermann In-Reply-To: <50A0E902.3080201@freebsd.org> References: <20121110132019.GP73505@kib.kiev.ua> <50A0E902.3080201@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Nov 2012 07:47:49 -0700 Message-ID: <1352731669.1217.22.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Konstantin Belousov , Adrian Chadd , "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 14:47:56 -0000 On Mon, 2012-11-12 at 13:18 +0100, Andre Oppermann wrote: > > Well, what's the current set of best practices for allocating mbufs? > > If an allocation is driven by user space then you can use M_WAITOK. > > If an allocation is driven by the driver or kernel (callout and so on) > you do M_NOWAIT and handle a failure by trying again later either > directly by rescheduling the callout or by the upper layer retransmit > logic. > > On top of that individual mbuf allocation or stitching mbufs and > clusters together manually is deprecated. If every possible you > should use m_getm2(). root@pico:/root # man m_getm2 No manual entry for m_getm2 So when you say manually stitching mbufs together is deprecated, I take you mean in the case where you're letting the mbuf routines allocate the actual buffer space for you? I've got an ethernet driver on an ARM SoC in which the hardware receives into a series of buffers fixed at 128 bytes. Right now the code is allocating a cluster and then looping using m_append() to reassemble these buffers back into a full contiguous frame in a cluster. I was going to have a shot at using MEXTADD() to manually string the series of hardware/dma buffers together without copying the data. Is that sort of usage still a good idea? (And would it actually be a performance win? If I hand it off to the net stack and an m_pullup() or similar is going to happen along the way anyway, I might as well do it at driver level.) -- Ian