On 24/04/2022 16.30, Jens Axboe wrote:
On 4/24/22 7:04 AM, Avi Kivity wrote:
On 23/04/2022 20.30, Jens Axboe wrote:
On 4/23/22 10:23 AM, Avi Kivity wrote:
Perhaps the interface should be kept separate from io_uring. e.g. use
a pidfd to represent the address space, and then issue
IORING_OP_PREADV/IORING_OP_PWRITEV to initiate dma. Then one can copy
across process boundaries.
Then you just made it a ton less efficient, particularly if you used the
vectored read/write. For this to make sense, I think it has to be a
separate op. At least that's the only implementation I'd be willing to
entertain for the immediate copy.
Sorry, I caused a lot of confusion by bundling immediate copy and a
DMA engine interface. For sure the immediate copy should be a direct
implementation like you posted!
User-to-user copies are another matter. I feel like that should be a
stand-alone driver, and that io_uring should be an io_uring-y way to
access it. Just like io_uring isn't an NVMe driver.
Not sure I understand your logic here or the io_uring vs nvme driver
reference, to be honest. io_uring _is_ a standalone way to access it,
you can use it sync or async through that.
If you're talking about a standalone op vs being useful from a command
itself, I do think both have merit and I can see good use cases for
both.
I'm saying that if dma is exposed to userspace, it should have a regular
synchronous interface (maybe open("/dev/dma"), maybe something else).
io_uring adds asynchrony to everything, but it's not everything's driver.
Anyway maybe we drifted off somewhere and this should be decided by
pragmatic concerns (like whatever the author of the driver prefers).
For outside of io_uring, you're looking at a sync
interface, which I think already exists for this (ioctls?).
Yes, it would be a asynchronous interface. I don't know if one exists,
but I can't claim to have kept track.
Again not following. So you're saying there should be a 2nd async
interface for it?
No. And I misspelled "synchronous" as "asynchronous" (I was agreeing
with you that it would be a sync interface).
The kernel itself should find the DMA engine useful for things like
memory compaction.
That's a very different use case though and just deals with wiring it up
internally.
Let's try and keep the scope here reasonable, imho nothing good comes
out of attempting to do all the things at once.
For sure, I'm just noting that the DMA engine has many different uses
and so deserves an interface that is untied to io_uring.
And again, not following, what's the point of having 2 interfaces for
the same thing? I can sort of agree if one is just the basic ioctl kind
of interface, a basic sync one. But outside of that I'm a bit puzzled as
to why that would be useful at all.
Yes I meant the basic sync one. Sorry I caused quite a lot of confusion
here!
