linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "Gal Pressman" <galpress@amazon.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Doug Ledford" <dledford@redhat.com>,
	"open list:DMA BUFFER SHARING FRAMEWORK"
	<linux-media@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-rdma <linux-rdma@vger.kernel.org>,
	"Oded Gabbay" <ogabbay@habana.ai>,
	"Tomer Tayar" <ttayar@habana.ai>,
	"Yossi Leybovich" <sleybo@amazon.com>,
	"Alexander Matushevsky" <matua@amazon.com>,
	"Leon Romanovsky" <leonro@nvidia.com>,
	"Jianxin Xiong" <jianxin.xiong@intel.com>,
	"John Hubbard" <jhubbard@nvidia.com>
Subject: Re: [RFC] Make use of non-dynamic dmabuf in RDMA
Date: Thu, 19 Aug 2021 20:06:02 -0300	[thread overview]
Message-ID: <20210819230602.GU543798@ziepe.ca> (raw)
In-Reply-To: <CAKMK7uGZ_eX+XfYJU6EkKEOVrHz3q6QMxaEbyyD3_1iqj9YSjw@mail.gmail.com>

On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman <galpress@amazon.com> wrote:
> >
> > Hey all,
> >
> > Currently, the RDMA subsystem can only work with dynamic dmabuf
> > attachments, which requires the RDMA device to support on-demand-paging
> > (ODP) which is not common on most devices (only supported by mlx5).
> >
> > While the dynamic requirement makes sense for certain GPUs, some devices
> > (such as habanalabs) have device memory that is always "pinned" and do
> > not need/use the move_notify operation.
> >
> > The motivation of this RFC is to use habanalabs as the dmabuf exporter,
> > and EFA as the importer to allow for peer2peer access through libibverbs.
> >
> > This draft patch changes the dmabuf driver to differentiate between
> > static/dynamic attachments by looking at the move_notify op instead of
> > the importer_ops struct, and allowing the peer2peer flag to be enabled
> > in case of a static exporter.
> >
> > Thanks
> >
> > Signed-off-by: Gal Pressman <galpress@amazon.com>
> 
> Given that habanalabs dma-buf support is very firmly in limbo (at
> least it's not yet in linux-next or anywhere else) I think you want to
> solve that problem first before we tackle the additional issue of
> making p2p work without dynamic dma-buf. Without that it just doesn't
> make a lot of sense really to talk about solutions here.

I have been thinking about adding a dmabuf exporter to VFIO, for
basically the same reason habana labs wants to do it.

In that situation we'd want to see an approach similar to this as well
to have a broad usability.

The GPU drivers also want this for certain sophisticated scenarios
with RDMA, the intree drivers just haven't quite got there yet.

So, I think it is worthwhile to start thinking about this regardless
of habana labs.

Jason

  reply	other threads:[~2021-08-19 23:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18  7:43 [RFC] Make use of non-dynamic dmabuf in RDMA Gal Pressman
2021-08-18  8:00 ` Christian König
2021-08-18  8:37   ` Gal Pressman
2021-08-18  9:34 ` Daniel Vetter
2021-08-19 23:06   ` Jason Gunthorpe [this message]
2021-08-20  7:25     ` Daniel Vetter
2021-08-20 12:33       ` Jason Gunthorpe
2021-08-20 12:58         ` Gal Pressman
2021-08-20 14:32           ` Jason Gunthorpe
2021-08-21  9:16             ` Gal Pressman
2021-08-23 10:43               ` Christian König
2021-08-24  9:06                 ` Gal Pressman
2021-08-24  9:32                   ` Christian König
2021-08-24 17:27                     ` John Hubbard
2021-08-24 17:32                       ` Jason Gunthorpe
2021-08-24 17:35                         ` John Hubbard
2021-08-24 19:15                           ` Dave Airlie
2021-08-24 19:30                             ` Jason Gunthorpe
2021-08-24 19:43                             ` Alex Deucher
2021-08-24 20:00                               ` Xiong, Jianxin
2021-08-25  6:17                         ` Christian König
2021-08-25  6:47                           ` John Hubbard
2021-08-25 12:18                           ` Jason Gunthorpe
2021-08-25 12:27                             ` Christian König
2021-08-25 12:38                               ` Jason Gunthorpe
2021-08-25 13:51                                 ` Christian König
2021-08-25 14:47                                   ` Jason Gunthorpe
2021-08-25 15:14                                     ` Christian König
2021-08-25 15:49                                       ` Jason Gunthorpe
2021-08-25 16:02                                       ` Oded Gabbay
2021-09-01 11:20                         ` Gal Pressman
2021-09-01 11:24                           ` Christian König
2021-09-02  6:56                             ` Gal Pressman

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=20210819230602.GU543798@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dledford@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=galpress@amazon.com \
    --cc=jhubbard@nvidia.com \
    --cc=jianxin.xiong@intel.com \
    --cc=leonro@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=matua@amazon.com \
    --cc=ogabbay@habana.ai \
    --cc=sleybo@amazon.com \
    --cc=sumit.semwal@linaro.org \
    --cc=ttayar@habana.ai \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).