From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 15:23:47 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 609D7692 for ; Mon, 12 Nov 2012 15:23:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B6D3A8FC1D for ; Mon, 12 Nov 2012 15:23:46 +0000 (UTC) Received: (qmail 2751 invoked from network); 12 Nov 2012 16:58:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2012 16:58:07 -0000 Message-ID: <50A1147E.2070807@freebsd.org> Date: Mon, 12 Nov 2012 16:23:42 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Memory reserves or lack thereof References: <20121110132019.GP73505@kib.kiev.ua> <50A0E902.3080201@freebsd.org> <1352731669.1217.22.camel@revolution.hippie.lan> In-Reply-To: <1352731669.1217.22.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 15:23:47 -0000 On 12.11.2012 15:47, Ian Lepore wrote: > 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 Oops... Have to fix that. > 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 mean allocating an mbuf, a cluster and then stitching them together. You can it in one with m_getcl(). > 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? That really depends on the particular usage. Attaching the 128 byte buffers to mbufs probably isn't much of a win considering an mbuf is 256 bytes in size. You could just as well copy each 128 buf into the data section. Allocating a 2K cluster and copying into it is more efficient on the overall system. > 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.) If you properly m_align() the mbuf cluster before you copy into it there shouldn't be any m_pullup's happening. -- Andre