Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Nov 2012 16:23:42 +0100
From:      Andre Oppermann <andre@freebsd.org>
To:        Ian Lepore <freebsd@damnhippie.dyndns.org>
Cc:        alc@freebsd.org, Konstantin Belousov <kostikbel@gmail.com>, Adrian Chadd <adrian@freebsd.org>, "Sears, Steven" <Steven.Sears@netapp.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Memory reserves or lack thereof
Message-ID:  <50A1147E.2070807@freebsd.org>
In-Reply-To: <1352731669.1217.22.camel@revolution.hippie.lan>
References:  <A6DE036C6A90C949A25CE89E844237FB2086970A@SACEXCMBX01-PRD.hq.netapp.com> <20121110132019.GP73505@kib.kiev.ua> <CAJUyCcOKHH3TO6qaK9V7UY2HW%2Bp6T74DUUdmbSi4eeGyofrTdQ@mail.gmail.com> <CAJ-Vmo=tk_yiukE_uZzDAgh6Q1RP=5Jz1G0heq%2BcANJ1di8Wzg@mail.gmail.com> <50A0E902.3080201@freebsd.org> <1352731669.1217.22.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A1147E.2070807>