Thread (87 messages) 87 messages, 8 authors, 2021-10-05

Re: [PATCH v3 00/20] Userspace P2PDMA with O_DIRECT NVMe devices

From: Logan Gunthorpe <logang@deltatee.com>
Date: 2021-09-29 23:52:50
Also in: linux-iommu, linux-mm, linux-nvme, linux-pci, lkml


On 2021-09-29 5:36 p.m., Jason Gunthorpe wrote:
On Wed, Sep 29, 2021 at 05:28:38PM -0600, Logan Gunthorpe wrote:
quoted

On 2021-09-29 5:21 p.m., Jason Gunthorpe wrote:
quoted
On Wed, Sep 29, 2021 at 03:50:02PM -0600, Logan Gunthorpe wrote:
quoted

On 2021-09-28 2:02 p.m., Jason Gunthorpe wrote:
quoted
On Thu, Sep 16, 2021 at 05:40:40PM -0600, Logan Gunthorpe wrote:
quoted
Hi,

This patchset continues my work to add userspace P2PDMA access using
O_DIRECT NVMe devices. My last posting[1] just included the first 13
patches in this series, but the early P2PDMA cleanup and map_sg error
changes from that series have been merged into v5.15-rc1. To address
concerns that that series did not add any new functionality, I've added
back the userspcae functionality from the original RFC[2] (but improved
based on the original feedback).
I really think this is the best series yet, it really looks nice
overall. I know the sg flag was a bit of a debate at the start, but it
serves an undeniable purpose and the resulting standard DMA APIs 'just
working' is really clean.
Actually, so far, nobody has said anything negative about using the SG flag.
quoted
There is more possible here, we could also pass the new GUP flag in the
ib_umem code..
Yes, that would be very useful.
You might actually prefer to do that then the bio changes to get the
infrastructur merged as it seems less "core"
I'm a little bit more concerned about my patch set growing too large.
It's already at 20 patches and I think I'll need to add a couple more
based on the feedback you've already provided. So I'm leaning toward
pushing more functionality as future work.
I mean you could postpone the three block related patches and use a
single ib_umem patch instead as the consumer.
I think that's not a very compelling use case given the only provider of
these VMAs is an NVMe block device. My patch set enables a real world
use (copying data between NVMe devices P2P through the CMB with O_DIRECT).

Being able to read or write a CMB with RDMA and only RDMA is not very
compelling.

Logan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help