All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
	"Christian Koenig" <christian.koenig@amd.com>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Simona Vetter" <simona.vetter@ffwll.ch>
Subject: Re: [RFC v2 1/8] dma-buf: Add support for map/unmap APIs for interconnects
Date: Mon, 27 Oct 2025 14:47:23 -0300	[thread overview]
Message-ID: <20251027174723.GB1018328@nvidia.com> (raw)
In-Reply-To: <20251027044712.1676175-2-vivek.kasireddy@intel.com>

On Sun, Oct 26, 2025 at 09:44:13PM -0700, Vivek Kasireddy wrote:
> For the map operation, the dma-buf core will create an xarray but
> the exporter needs to populate it with the interconnect specific
> addresses. And, similarly for unmap, the exporter is expected to
> cleanup the individual entries of the xarray.

I don't think we should limit this to xarrays, nor do I think it is a
great datastructure for what is usually needed here..

I just posted the patches showing what iommufd needs, and it wants
something like

struct mapping {
   struct p2p_provider *provider;
   size_t nelms;
   struct phys_vec *phys;
};

Which is not something that make sense as an xarray.

I think the interconnect should have its own functions for map/unmap,
ie instead of trying to have them as a commmon
dma_buf_interconnect_ops do something like

struct dma_buf_interconnect_ops {
        const char *name;
        bool (*supports_interconnects)(struct dma_buf_attachment *attach,
                                      const struct dma_buf_interconnect_match *,
                                      unsigned int num_ics);
};

struct dma_buf_iov_interconnect_ops {
     struct dma_buf_interconnect_ops ic_ops;
     struct xx *(*map)(struct dma_buf_attachment *attach,
     	 		   unsigned int *bar_number,
			   size_t *nelms);
     // No unmap for iov
};

static inline struct xx *dma_buf_iov_map(struct dma_buf_attachment *attach,
     	 		   unsigned int *bar_number,
			   size_t *nelms)
{
     return container_of(attach->ic_ops, struct dma_buf_iov_interconnect_ops, ic_ops)->map(
                 attach, bar_number, nelms));
}

> +/**
> + * dma_buf_attachment_is_dynamic - check if the importer can handle move_notify.
> + * @attach: the attachment to check
> + *
> + * Returns true if a DMA-buf importer has indicated that it can handle dmabuf
> + * location changes through the move_notify callback.
> + */
> +static inline bool
> +dma_buf_attachment_is_dynamic(struct dma_buf_attachment *attach)
> +{
> +	return !!attach->importer_ops;
> +}

Why is this in this patch?

I also think this patch should be second in the series, it makes more
sense to figure out how to attach with an interconnect then show how
to map/unmap with that interconnect

Like I'm not sure why this introduces allow_ic?

Jason

  reply	other threads:[~2025-10-27 17:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-27  4:44 [RFC v2 0/8] dma-buf: Add support for mapping dmabufs via interconnects Vivek Kasireddy
2025-10-27  4:44 ` [RFC v2 1/8] dma-buf: Add support for map/unmap APIs for interconnects Vivek Kasireddy
2025-10-27 17:47   ` Jason Gunthorpe [this message]
2025-10-28  5:39     ` Kasireddy, Vivek
2025-10-28 12:21       ` Jason Gunthorpe
2025-10-27  4:44 ` [RFC v2 2/8] dma-buf: Add a helper to match interconnects between exporter/importer Vivek Kasireddy
2025-10-27 18:18   ` Jason Gunthorpe
2025-10-28  6:04     ` Kasireddy, Vivek
2025-10-27  4:44 ` [RFC v2 3/8] dma-buf: Create and expose IOV interconnect to all exporters/importers Vivek Kasireddy
2025-10-27  4:44 ` [RFC v2 4/8] vfio/pci/dmabuf: Add support for IOV interconnect Vivek Kasireddy
2025-10-28  2:00   ` Matthew Brost
2025-10-28  5:05     ` Kasireddy, Vivek
2025-10-27  4:44 ` [RFC v2 5/8] drm/xe/dma_buf: " Vivek Kasireddy
2025-10-27  4:44 ` [RFC v2 6/8] drm/xe/pf: Add a helper function to get a VF's backing object in LMEM Vivek Kasireddy
2025-10-27  4:44 ` [RFC v2 7/8] drm/xe/bo: Create new dma_addr array for dmabuf BOs associated with VFs Vivek Kasireddy
2025-10-27  4:44 ` [RFC v2 8/8] drm/xe/pt: Add an additional check for dmabuf BOs while doing bind Vivek Kasireddy
2025-10-29  0:27 ` [RFC v2 0/8] dma-buf: Add support for mapping dmabufs via interconnects Jason Gunthorpe
2025-10-29  9:25   ` Leon Romanovsky
2025-10-29 11:53     ` Jason Gunthorpe
2025-10-30  6:17   ` Kasireddy, Vivek
2025-10-30 13:43     ` Jason Gunthorpe
2025-10-31  5:15       ` Kasireddy, Vivek
2025-10-31  7:46         ` Christian König
2025-10-31 13:16           ` Jason Gunthorpe
2026-01-23 22:50         ` Jason Gunthorpe
2026-01-27  6:03           ` Kasireddy, Vivek

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=20251027174723.GB1018328@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=simona.vetter@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=vivek.kasireddy@intel.com \
    /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 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.