On 6/10/24 16:41, Mina Almasry wrote:
On Mon, Jun 10, 2024 at 5:38 AM Christian König
<christian.koenig@xxxxxxx> wrote:
Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
On 6/10/24 01:37, David Wei wrote:
On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it seems to compose poorly if you can only use the io_uring
lifecycle model with io_uring registered memory, and not with DMABUF
memory registered through Mina's mechanism.
By this, do you mean io_uring must be exclusively used to use this
feature?
And you'd rather see the two decoupled, so userspace can register w/ say
dmabuf then pass it to io_uring?
Personally, I have no clue what Jason means. You can just as
well say that it's poorly composable that write(2) to a disk
cannot post a completion into a XDP ring, or a netlink socket,
or io_uring's main completion queue, or name any other API.
There is no reason you shouldn't be able to use your fast io_uring
completion and lifecycle flow with DMABUF backed memory. Those are not
widly different things and there is good reason they should work
together.
Well there is the fundamental problem that you can't use io_uring to
implement the semantics necessary for a dma_fence.
That's why we had to reject the io_uring work on DMA-buf sharing from
Google a few years ago.
Any chance someone can link me to this? io_uring, as far as my
primitive understanding goes, is not yet very adopted at Google, and
I'm curious what this effort is.
I'm curious as well, I don't remember it floating anywhere in mailing
lists. The only discussion I recall was about
DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, but it didn't get through only because
someone pushed for evenfds.
--
Pavel Begunkov
