From: Zhu Yanjun <yanjun.zhu@linux.dev> To: Jason Gunthorpe <jgg@nvidia.com>, lsf-pc@lists.linuxfoundation.org, linux-mm@kvack.org, iommu@lists.linux.dev, linux-rdma@vger.kernel.org Cc: Matthew Wilcox <willy@infradead.org>, Christoph Hellwig <hch@lst.de>, Joao Martins <joao.m.martins@oracle.com>, John Hubbard <jhubbard@nvidia.com>, Logan Gunthorpe <logang@deltatee.com>, Ming Lei <ming.lei@redhat.com>, linux-block@vger.kernel.org, netdev@vger.kernel.org, dri-devel@lists.freedesktop.org, nvdimm@lists.linux.dev Subject: Re: [LSF/MM/BPF proposal]: Physr discussion Date: Thu, 26 Jan 2023 09:45:21 +0800 [thread overview] Message-ID: <56ce760f-188c-3a1d-0512-9122247ea100@linux.dev> (raw) In-Reply-To: <Y8v+qVZ8OmodOCQ9@nvidia.com> 在 2023/1/21 23:03, Jason Gunthorpe 写道: > I would like to have a session at LSF to talk about Matthew's > physr discussion starter: > > https://lore.kernel.org/linux-mm/YdyKWeU0HTv8m7wD@casper.infradead.org/ > > I have become interested in this with some immediacy because of > IOMMUFD and this other discussion with Christoph: > > https://lore.kernel.org/kvm/4-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com/ I read through the above patches. I am interested in the dma-buf. Zhu Yanjun > > Which results in, more or less, we have no way to do P2P DMA > operations without struct page - and from the RDMA side solving this > well at the DMA API means advancing at least some part of the physr > idea. > > So - my objective is to enable to DMA API to "DMA map" something that > is not a scatterlist, may or may not contain struct pages, but can > still contain P2P DMA data. From there I would move RDMA MR's to use > this new API, modify DMABUF to export it, complete the above VFIO > series, and finally, use all of this to add back P2P support to VFIO > when working with IOMMUFD by allowing IOMMUFD to obtain a safe > reference to the VFIO memory using DMABUF. From there we'd want to see > pin_user_pages optimized, and that also will need some discussion how > best to structure it. > > I also have several ideas on how something like physr can optimize the > iommu driver ops when working with dma-iommu.c and IOMMUFD. > > I've been working on an implementation and hope to have something > draft to show on the lists in a few weeks. It is pretty clear there > are several interesting decisions to make that I think will benefit > from a live discussion. > > Providing a kernel-wide alternative to scatterlist is something that > has general interest across all the driver subsystems. I've started to > view the general problem rather like xarray where the main focus is to > create the appropriate abstraction and then go about transforming > users to take advatange of the cleaner abstraction. scatterlist > suffers here because it has an incredibly leaky API, a huge number of > (often sketchy driver) users, and has historically been very difficult > to improve. > > The session would quickly go over the current state of whatever the > mailing list discussion evolves into and an open discussion around the > different ideas. > > Thanks, > Jason >
WARNING: multiple messages have this Message-ID (diff)
From: Zhu Yanjun <yanjun.zhu@linux.dev> To: Jason Gunthorpe <jgg@nvidia.com>, lsf-pc@lists.linuxfoundation.org, linux-mm@kvack.org, iommu@lists.linux.dev, linux-rdma@vger.kernel.org Cc: nvdimm@lists.linux.dev, John Hubbard <jhubbard@nvidia.com>, Matthew Wilcox <willy@infradead.org>, Ming Lei <ming.lei@redhat.com>, linux-block@vger.kernel.org, dri-devel@lists.freedesktop.org, netdev@vger.kernel.org, Joao Martins <joao.m.martins@oracle.com>, Logan Gunthorpe <logang@deltatee.com>, Christoph Hellwig <hch@lst.de> Subject: Re: [LSF/MM/BPF proposal]: Physr discussion Date: Thu, 26 Jan 2023 09:45:21 +0800 [thread overview] Message-ID: <56ce760f-188c-3a1d-0512-9122247ea100@linux.dev> (raw) In-Reply-To: <Y8v+qVZ8OmodOCQ9@nvidia.com> 在 2023/1/21 23:03, Jason Gunthorpe 写道: > I would like to have a session at LSF to talk about Matthew's > physr discussion starter: > > https://lore.kernel.org/linux-mm/YdyKWeU0HTv8m7wD@casper.infradead.org/ > > I have become interested in this with some immediacy because of > IOMMUFD and this other discussion with Christoph: > > https://lore.kernel.org/kvm/4-v2-472615b3877e+28f7-vfio_dma_buf_jgg@nvidia.com/ I read through the above patches. I am interested in the dma-buf. Zhu Yanjun > > Which results in, more or less, we have no way to do P2P DMA > operations without struct page - and from the RDMA side solving this > well at the DMA API means advancing at least some part of the physr > idea. > > So - my objective is to enable to DMA API to "DMA map" something that > is not a scatterlist, may or may not contain struct pages, but can > still contain P2P DMA data. From there I would move RDMA MR's to use > this new API, modify DMABUF to export it, complete the above VFIO > series, and finally, use all of this to add back P2P support to VFIO > when working with IOMMUFD by allowing IOMMUFD to obtain a safe > reference to the VFIO memory using DMABUF. From there we'd want to see > pin_user_pages optimized, and that also will need some discussion how > best to structure it. > > I also have several ideas on how something like physr can optimize the > iommu driver ops when working with dma-iommu.c and IOMMUFD. > > I've been working on an implementation and hope to have something > draft to show on the lists in a few weeks. It is pretty clear there > are several interesting decisions to make that I think will benefit > from a live discussion. > > Providing a kernel-wide alternative to scatterlist is something that > has general interest across all the driver subsystems. I've started to > view the general problem rather like xarray where the main focus is to > create the appropriate abstraction and then go about transforming > users to take advatange of the cleaner abstraction. scatterlist > suffers here because it has an incredibly leaky API, a huge number of > (often sketchy driver) users, and has historically been very difficult > to improve. > > The session would quickly go over the current state of whatever the > mailing list discussion evolves into and an open discussion around the > different ideas. > > Thanks, > Jason >
next prev parent reply other threads:[~2023-01-26 1:45 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-21 15:03 [LSF/MM/BPF proposal]: Physr discussion Jason Gunthorpe 2023-01-21 15:03 ` Jason Gunthorpe 2023-01-23 4:36 ` Matthew Wilcox 2023-01-23 4:36 ` Matthew Wilcox 2023-01-23 13:44 ` Jason Gunthorpe 2023-01-23 13:44 ` Jason Gunthorpe 2023-01-23 19:47 ` Bart Van Assche 2023-01-23 19:47 ` Bart Van Assche 2023-01-24 6:15 ` Chaitanya Kulkarni 2023-01-24 6:15 ` Chaitanya Kulkarni 2023-01-26 9:39 ` Mike Rapoport 2023-01-26 9:39 ` Mike Rapoport 2023-01-23 19:36 ` [Lsf-pc] " Dan Williams 2023-01-23 19:36 ` Dan Williams 2023-01-23 20:11 ` Matthew Wilcox 2023-01-23 20:11 ` Matthew Wilcox 2023-01-23 20:50 ` Dan Williams 2023-01-23 20:50 ` Dan Williams 2023-01-23 22:46 ` Matthew Wilcox 2023-01-26 19:38 ` Jason Gunthorpe 2023-01-26 19:38 ` Jason Gunthorpe 2023-01-26 1:45 ` Zhu Yanjun [this message] 2023-01-26 1:45 ` Zhu Yanjun 2023-02-28 20:59 ` T.J. Mercier 2023-02-28 20:59 ` T.J. Mercier 2023-04-17 19:59 ` Jason Gunthorpe 2023-04-17 19:59 ` Jason Gunthorpe
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=56ce760f-188c-3a1d-0512-9122247ea100@linux.dev \ --to=yanjun.zhu@linux.dev \ --cc=dri-devel@lists.freedesktop.org \ --cc=hch@lst.de \ --cc=iommu@lists.linux.dev \ --cc=jgg@nvidia.com \ --cc=jhubbard@nvidia.com \ --cc=joao.m.martins@oracle.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-rdma@vger.kernel.org \ --cc=logang@deltatee.com \ --cc=lsf-pc@lists.linuxfoundation.org \ --cc=ming.lei@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=nvdimm@lists.linux.dev \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.