Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem

[Kumar Gala <galak@kernel.crashing.org>]

On Mar 28, 2006, at 4:01 PM, Andrew Grover wrote:

> On 3/28/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> > > > Also, what do you think about adding an operation type (MEMCPY,  
> > > > XOR,
> > > > CRYPTO_AES, etc).  We can than validate if the operation type
> > > > expected is supported by the devices that exist.
> > >
> > > No objections, but this speculative support doesn't need to be in  
> > > our
> > > initial patchset.
> >
> > I don't consider it speculative.  The patch is for a generic DMA
> > engine interface.  That interface should encompass all users.  I have
> > a security/crypto DMA engine that I'd like to front with the generic
> > DMA interface today.  Also, I believe there is another Intel group
> > with an XOR engine that had a similar concept called ADMA posted a
> > while ago.
>
> Please submit patches then. We will be doing another rev of the I/OAT
> patch very soon, which you will be able to patch against. Or, once the
> patch gets in mainline then we can enhance it. Code in the Linux
> kernel is never "done", and the burden of implementing additional
> functionality falls on those who want it.

I completely understand that.  However, I think putting something  
into mainline that only works or solves the particular problem you  
have is a bad idea.  I'll provide patches for the changes I'd like to  
see.  However, I figured a little discussion on the subject before I  
went off an spent time on it was worth while.

> > Can you explain what the semantics are.
> >
> > It's been a little while since I posted so my thoughts on the subject
> > are going to take a little while to come back to me :)
>
> Yeah. Basically you register as a DMA client, and say how many DMA
> channels you want. Our net_dma patch for example uses multiple
> channels to help lock contention. Then when channels are available
> (i.e. a DMA device added or another client gives them up) then you get
> a callback. If the channel goes away (i.e. DMA device is removed
> (theoretically possible but practically never happens) or *you* are
> going away and change your request to 0 channels) then you get a
> remove callback.

Do you only get callback when a channel is available?  How do you  
decide to do to provide PIO to the client?

A client should only request multiple channel to handle multiple  
concurrent operations.

> This gets around the problem of DMA clients registering (and therefore
> not getting) channels simply because they init before the DMA device
> is discovered.

What do you expect to happen in a system in which the channels are  
over subscribed?

Do you expect the DMA device driver to handle scheduling of channels  
between multiple clients?

- kumar

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