Re: memory access op ideas

[Jens Axboe <axboe@kernel.dk>]

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.

>>   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?

>>> 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.

-- 
Jens Axboe