On 4/22/22 21:03, Walker, Benjamin wrote:
On 4/22/2022 7:50 AM, Jens Axboe wrote:
On 4/13/22 4:33 AM, Avi Kivity wrote:
Unfortunately, only ideas, no patches. But at least the first seems very easy.
- IORING_OP_MEMCPY_IMMEDIATE - copy some payload included in the op
itself (1-8 bytes) to a user memory location specified by the op.
Linked to another op, this can generate an in-memory notification
useful for busy-waiters or the UMWAIT instruction
This would be useful for Seastar, which looks at a timer-managed
memory location to check when to break computation loops.
This one would indeed be trivial to do. If we limit the max size
supported to eg 8 bytes like suggested, then it could be in the sqe
itself and just copied to the user address specified.
Eg have sqe->len be the length (1..8 bytes), sqe->addr the destination
address, and sqe->off the data to copy.
If you'll commit to testing this, I can hack it up pretty quickly...
- IORING_OP_MEMCPY - asynchronously copy memory
Some CPUs include a DMA engine, and io_uring is a perfect interface to
exercise it. It may be difficult to find space for two iovecs though.
I've considered this one in the past too, and it is indeed an ideal fit
in terms of API. Outside of the DMA engines, it can also be used to
offload memcpy to a GPU, for example.
The io_uring side would not be hard to wire up, basically just have the
sqe specfy source, destination, length. Add some well defined flags
depending on what the copy engine offers, for example.
But probably some work required here in exposing an API and testing
etc...
I'm about to send a set of patches to associate an io_uring with a dmaengine channel to this list. I'm not necessarily thinking of using it to directly drive the DMA engine itself (although we could, and there's some nice advantages to that), but rather as a way to offload data copies/transforms on existing io_uring operations. My primary focus has been the copy between kernel and user space when receiving from a socket.
Upcoming DMA engines also support SVA, allowing them to copy from kernel to user without page pinning. We've got patches for full SVA enabling in dmaengine prepared, such that each io_uring can allocate a PASID describing the user+kernel address space for the current context, allocate a channel via dmaengine and assign it the PASID, and then do DMA between kernel/user with new dmaengine APIs without any page pinning.
As preparation, I have submitted a series to dmaengine that allows for polling and out-of-order completions. See https://lore.kernel.org/dmaengine/20220201203813.3951461-1-benjamin.walker@xxxxxxxxx/T/#u. This is a necessary first step.
I'll get the patches out ASAP as an RFC. I'm sure my approach was entirely wrong, but you'll get the idea.
Please do. Sounds interesting and it will likely be nicely
aligned with our work/plans on p2p.
--
Pavel Begunkov
