linux-kernel - Re: [PATCH 1/3 v3] dma: document dma_{un}map_{single|sg}

lists.openwall.net		lists / announce john-users owl-users popa3d-users / xvendor oss-security / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4
Open Source and information security mailing list archives

This website is powered by Openwall GNU/*/Linux security-enhanced OS

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date:	Fri, 29 Feb 2008 19:11:32 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	benh@...nel.crashing.org
Subject: Re: [PATCH 1/3 v3] dma: document dma_{un}map_{single|sg}_attrs() interface

On Friday, February 29, 2008 6:56 pm Benjamin Herrenschmidt wrote:
> On Fri, 2008-02-29 at 12:37 -0600, James Bottomley wrote:
> > To be honest, I still don't like the name.  SYNC_ON_WRITE is the SN2
> > implementation.  What it's actually doing is implementing strict
> > ordering semantics.  I think it should really be
> > DMA_ATTR_STRICT_ORDERING (with a corresponding
> > DMA_ATTR_RELAXED_ORDERING).
> >
> > This means that if ever anyone sets a PCIe bridge to relaxed ordering
> > by
> > default, this attribute will also work for them.
>
> But that would be asking for trouble no ? I would expect pretty much
> everything to break appart with relaxed by default no ? Or I don't fully
> understand what your arch calls "relaxed"...

Depends on how the device completes commands and what the driver does to check 
for completion.  It would probably work fine in many cases.

> I do agree that we should aim for simple semantics, they should cover
> 99% of the needs, and leave some bit space or attribute space for archs
> to define private ones when really needed.
>
> In our case, I suspect that the two main thing we could define here for
> DMA that would be useful generally would be relaxed ordering (strict
> being the default) and maybe read prefetching (though that would be the
> default, maybe no prefetch). We -might- have use of separating relaxed
> ordering for read vs. writes, but that's pretty much it.

Sounds about right.  I've got to poke the PCIe 3.0 folks again about some of 
the potential ordering changes there; hopefully we can cover that stuff too 
with Arthur's approach.

Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/