From: Matthew Brost <matthew.brost@intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Christian König" <christian.koenig@amd.com>,
"Kasireddy Vivek" <vivek.kasireddy@intel.com>,
dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [RFC PATCH 1/2] dma-buf: Add support for private interconnects
Date: Thu, 25 Sep 2025 09:40:42 -0700 [thread overview]
Message-ID: <aNVwiiJs0mWXzcS8@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <2e518022d743762fc0c5bde8c0918ee47a18b0aa.camel@linux.intel.com>
On Thu, Sep 25, 2025 at 05:48:36PM +0200, Thomas Hellström wrote:
> On Thu, 2025-09-25 at 15:08 +0200, Thomas Hellström wrote:
> > Add a function to the dma_buf_attach_ops to indicate whether the
> > connection is a private interconnect. If so the function returns
> > the address to an interconnect-defined structure that can be
> > used for further negotiating.
> >
> > Also add a field to the dma_buf_attachment that indicates whether
> > a private interconnect is used by the attachment.
> >
> > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > ---
> > include/linux/dma-buf.h | 15 +++++++++++++++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index d58e329ac0e7..e7191edb2125 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -475,6 +475,19 @@ struct dma_buf_attach_ops {
> > * point to the new location of the DMA-buf.
> > */
> > void (*move_notify)(struct dma_buf_attachment *attach);
> > +
> > + /**
> > + * @supports_interconnect: [optional] - Does the driver
> > support a local interconnect?
> > + *
> > + * Does the importer support a private interconnect? The
> > interconnect is
> > + * identified using a unique address defined by the exporter
> > and declared
> > + * in a protocol header.
>
> Actually we'd probably want to use something like a
>
> struct dma_buf_interconnect {
> const char *name;
Maybe a field for private protocol type too?
> };
>
> Here, and for globally known interconnects have them
> instantiated somewhere common since there could be multiple exporters.
>
> > (RFC: Should this be a struct instead).
> > + *
> > + * Return: A pointer to the interconnect-private attach_ops
> > structure if supported,
> > + * %NULL otherwise.
> > + */
> > + const void *(*supports_interconnect)(struct
> > dma_buf_attachment *attach,
> > + const void
> > *interconnect);
>
> And similarly for stricter type-checking the return value could be a
> struct dma_buf_interconnect_attach_ops {
> };
>
> which is subclassed for each interconnect-private attach ops.
>
> > };
> >
> > /**
> > @@ -484,6 +497,7 @@ struct dma_buf_attach_ops {
> > * @node: list of dma_buf_attachment, protected by dma_resv lock of
> > the dmabuf.
> > * @peer2peer: true if the importer can handle peer resources
> > without pages.
> > * @priv: exporter specific attachment data.
> > + * @interconnect: Private interconnect to use if any, NULL
> > otherwise.
> > * @importer_ops: importer operations for this attachment, if
> > provided
> > * dma_buf_map/unmap_attachment() must be called with the dma_resv
> > lock held.
> > * @importer_priv: importer specific attachment data.
> > @@ -503,6 +517,7 @@ struct dma_buf_attachment {
> > struct list_head node;
> > bool peer2peer;
> > const struct dma_buf_attach_ops *importer_ops;
> > + const void *interconnect;
>
> const struct dma_buf_interconnect *interconnect;
>
In general I think not using void * would be a good idea rather base
classes that can be subclassed. Since you have thought about this
already and there aren't comments on this patch maybe best to respin
with the subclasssing concepts?
Matt
> > void *importer_priv;
> > void *priv;
> > };
>
> /Thomas
>
next prev parent reply other threads:[~2025-09-25 16:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 13:08 [RFC PATCH 0/2] dma-buf private interconnect POC Thomas Hellström
2025-09-25 13:08 ` [RFC PATCH 1/2] dma-buf: Add support for private interconnects Thomas Hellström
2025-09-25 15:48 ` Thomas Hellström
2025-09-25 16:40 ` Matthew Brost [this message]
2025-09-25 13:08 ` [RFC PATCH 2/2] drm/xe/dma-buf: Add generic interconnect support framework Thomas Hellström
2025-09-25 13:14 ` ✗ CI.checkpatch: warning for dma-buf private interconnect POC Patchwork
2025-09-25 13:16 ` ✓ CI.KUnit: success " Patchwork
2025-09-25 13:33 ` ✗ CI.checksparse: warning " Patchwork
2025-09-25 13:56 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-09-25 18:03 ` ✗ Xe.CI.Full: " Patchwork
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=aNVwiiJs0mWXzcS8@lstrano-desk.jf.intel.com \
--to=matthew.brost@intel.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=maarten.lankhorst@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox