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 2/8] dma-buf: Add a helper to match interconnects between exporter/importer
Date: Mon, 27 Oct 2025 15:18:53 -0300 [thread overview]
Message-ID: <20251027181853.GC1018328@nvidia.com> (raw)
In-Reply-To: <20251027044712.1676175-3-vivek.kasireddy@intel.com>
On Sun, Oct 26, 2025 at 09:44:14PM -0700, Vivek Kasireddy wrote:
> +/**
> + * dma_buf_match_interconnects - determine if there is a specific interconnect
> + * that is supported by both exporter and importer.
> + * @attach: [in] attachment to populate ic_match field
> + * @exp: [in] array of interconnects supported by exporter
> + * @exp_ics: [in] number of interconnects supported by exporter
> + * @imp: [in] array of interconnects supported by importer
> + * @imp_ics: [in] number of interconnects supported by importer
> + *
> + * This helper function iterates through the list interconnects supported by
> + * both exporter and importer to find a match. A successful match means that
> + * a common interconnect type is supported by both parties and the exporter's
> + * match_interconnect() callback also confirms that the importer is compatible
> + * with the exporter for that interconnect type.
Document which of the exporter/importer is supposed to call this
> + *
> + * If a match is found, the attach->ic_match field is populated with a copy
> + * of the exporter's match data.
> + * Return: true if a match is found, false otherwise.
> + */
> +bool dma_buf_match_interconnects(struct dma_buf_attachment *attach,
> + const struct dma_buf_interconnect_match *exp,
> + unsigned int exp_ics,
> + const struct dma_buf_interconnect_match *imp,
> + unsigned int imp_ics)
> +{
> + const struct dma_buf_interconnect_ops *ic_ops;
> + struct dma_buf_interconnect_match *ic_match;
> + struct dma_buf *dmabuf = attach->dmabuf;
> + unsigned int i, j;
> +
> + if (!exp || !imp)
> + return false;
> +
> + if (!attach->allow_ic)
> + return false;
Seems redundant with this check for ic_ops == NULL:
> + ic_ops = dmabuf->ops->interconnect_ops;
> + if (!ic_ops || !ic_ops->match_interconnect)
> + return false;
This seems like too much of a maze to me..
I think you should structure it like this. First declare an interconnect:
struct dma_buf_interconnect iov_interconnect {
.name = "IOV interconnect",
.match =..
}
Then the exporters "subclass"
struct dma_buf_interconnect_ops vfio_iov_interconnect {
.interconnect = &iov_interconnect,
.map = vfio_map,
}
I guess no container_of technique..
Then in VFIO's attach trigger the new code:
const struct dma_buf_interconnect_match vfio_exp_ics[] = {
{&vfio_iov_interconnect},
};
dma_buf_match_interconnects(attach, &vfio_exp_ics))
Which will callback to the importer:
static const struct dma_buf_attach_ops xe_dma_buf_attach_ops = {
.get_importer_interconnects
}
dma_buf_match_interconnects() would call
aops->get_importer_interconnects
and matchs first on .interconnect, then call the interconnect->match
function with exp/inpt match structs if not NULL.
> +struct dma_buf_interconnect_match {
> + const struct dma_buf_interconnect *type;
> + struct device *dev;
> + unsigned int bar;
> +};
This should be more general, dev and bar are unique to the iov
importer. Maybe just simple:
struct dma_buf_interconnect_match {
struct dma_buf_interconnect *ic; // no need for type
const struct dma_buf_interconnct_ops *exporter_ic_ops;
u64 match_data[2]; // dev and bar are IOV specific, generalize
};
Then some helper
const struct dma_buf_interconnect_match supports_ics[] = {
IOV_INTERCONNECT(&vfio_iov_interconnect, dev, bar),
}
And it would be nice if interconnect aware drivers could more easially
interwork with non-interconnect importers.
So I'd add a exporter type of 'p2p dma mapped scatterlist' that just
matches the legacy importer.
Jason
next prev parent reply other threads:[~2025-10-27 18:19 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
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 [this message]
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=20251027181853.GC1018328@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.