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

On 3/28/06, Kumar Gala [off-list ref] wrote:

quoted

quoted

quoted

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.

quoted

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