Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 May 2012 19:46:23 +0200
From:      Daan Vreeken <Daan@vitsch.nl>
To:        freebsd-arm@freebsd.org
Cc:        hackers@freebsd.org, Svatopluk Kraus <onwahe@gmail.com>, Richard Hodges <richard@hodges.org>
Subject:   Re: ARM + CACHE_LINE_SIZE + DMA
Message-ID:  <201205211946.23306.Daan@vitsch.nl>
In-Reply-To: <1337617221.2516.38.camel@revolution.hippie.lan>
References:  <CAFHCsPUdZXGKFvmVGgaEUsfhwd28mNVGaY84ExcJp=ogQxzPJQ@mail.gmail.com> <CAFHCsPVxkhNfiTQp7gvjfonfTjoG-28RgNrG=%2BdxbGhzxqY%2BDg@mail.gmail.com> <1337617221.2516.38.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ian (and list),

just commenting on the mbuf part :

On Monday 21 May 2012 18:20:21 Ian Lepore wrote:
> On Fri, 2012-05-18 at 16:13 +0200, Svatopluk Kraus wrote:
> > On Thu, May 17, 2012 at 10:07 PM, Ian Lepore
> > <freebsd@damnhippie.dyndns.org> wrote:
> > > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote:
> > >> Hi,
...
> > What I can do in a driver it's not so simple in case of OS buffers
> > like mbufs. I can check how mbufs are used in current implementation
> > and say, yes, it's safe to use them unaligned. However, it can be
> > changed in next release if anybody won't take care of it. It would be
> > nice to have a maintained list of OS buffers which are DMA safe in
> > respect of CACHE_LINE_SIZE. Is the flag and the list interesting for
> > somebody else?
>
> I don't have a definitive answer for this, but my assumption has always
> been that once an mbuf is handed to a driver (for example, when it's
> added to an interface's send queue), the driver then "owns" that mbuf
> and nothing else in the system will touch it until the driver makes a
> call to hand it off or free it.  If that assumption is true, a driver
> could make good use of a BUS_DMA_UNALIGNED_SAFE flag with mbufs.
>
> The part that scares me about my assumption is the m_ext.ref_cnt field
> of the mbuf.  Its existance seems to imply that multiple entities
> concurrently have an interest in the data.  On the other hand, the lack
> of any built in provisions for locking seems to imply that concurrent
> access isn't happening, or perhaps it implies that any required
> synchronization is temporal rather than lock-based.
>
> I've never found anything in writing that explains mbuf usage
> conventions at this level of detail.

This assumption isn't always true. 'man 9 mbuf' mentions this, but not in one 
place. M_WRITABLE() can be used to tell wether or not you're allowed to 
modify an mbuf. If it returns false, you can create a writable copy of the 
mbuf and alter the copy instead of the original.
A writable copy of an mbuf can be made using m_dup().

Writing to non-writable mbuf's will cause data corruption in e.g. BPF and TCP 
retransmits (even in the non-SMP case).


Regards,
-- 
Daan Vreeken
Vitsch Electronics
http://Vitsch.nl
tel: +31-(0)40-7113051
KvK nr: 17174380



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