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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

On 3/28/06, Kumar Gala <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux