On 3/30/06, Kumar Gala <[EMAIL PROTECTED]> wrote:
> I was under the impression that the DMA engine would provide a "sync"
> cpu based memcpy (PIO) if a real HW channel wasn't avail, if this is
> left to the client that's fine. So how does the client know he
> should use normal memcpy()?
It has to keep track of what DMA channel to use, which it gets when
the channel ADDED callback happens. So it's basically
if (some_client_struct->dma_chan)
dma_memcpy()
else
memcpy()
The async memcpy has the added requirement that at some point the
client must verify the copies have been completed, so doing async
memcopies does require more work on the client's part.
> Sounds good for a start. Have you given any thoughts on handling
> priorities between clients?
>
> I need to take a look at the latest patches. How would you guys like
> modifications?
Haven't given any thought to priorities yet -- we've been focusing on
getting the 1 client case to perform well. :)
Chris posted a link to this: git://198.78.49.142/~cleech/linux-2.6
branch ioat-2.6.17
So you can post patches against that, or the patches posted here apply
against davem's git tree.
Regards -- Andy
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
