From: "Christian König" <christian.koenig@amd.com>
To: Zhiping Zhang <zhipingz@meta.com>,
Alex Williamson <alex@shazbot.org>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
Sumit Semwal <sumit.semwal@linaro.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
kvm@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-pci@vger.kernel.org, netdev@vger.kernel.org,
dri-devel@lists.freedesktop.org, Keith Busch <kbusch@kernel.org>,
Yochai Cohen <yochai@nvidia.com>,
Yishai Hadas <yishaih@nvidia.com>
Subject: Re: [PATCH v6 3/5] dma-buf: add optional get_tph() callback
Date: Tue, 9 Jun 2026 10:10:15 +0200 [thread overview]
Message-ID: <40243782-e4ff-435c-ae40-3ac1c7c4815e@amd.com> (raw)
In-Reply-To: <20260608185646.4085127-4-zhipingz@meta.com>
On 6/8/26 20:56, Zhiping Zhang wrote:
> Add an optional dma-buf get_tph callback so an exporter can return TPH
> (TLP Processing Hints) metadata to an importer.
>
> 8-bit ST and 16-bit Extended ST are distinct namespaces in the PCIe TPH
> ST table and may both be present with different values. The importer
> passes its supported steering-tag width and the exporter returns the
> matching value, or -EOPNOTSUPP if no metadata is available for that
> width.
>
> The callback is intentionally exporter-owned and optional. The exporter
> owns the completing address space for the dma-buf, so only it can decide
> whether it has meaningful TPH metadata for that completer. The dma-buf
> core keeps the returned ST/PH tuple opaque and simply provides a
> discoverable negotiation point between exporter and importer; exporters
> that cannot derive a useful tuple just return -EOPNOTSUPP.
>
> That keeps the kernel API generic rather than VFIO-specific. The first
> user is VFIO_DEVICE_FEATURE_DMA_BUF_TPH in vfio-pci, with the mlx5 RDMA
> driver as the first importer, but any future exporter that can derive a
> TPH tuple for its completing address space can reuse the same callback.
>
> Signed-off-by: Zhiping Zhang <zhipingz@meta.com>
> ---
> include/linux/dma-buf.h | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d1203da56fc5..8437dbe4a83e 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -113,6 +113,37 @@ struct dma_buf_ops {
> */
> void (*unpin)(struct dma_buf_attachment *attach);
>
> + /**
> + * @get_tph:
> + * @dmabuf: DMA buffer for which to retrieve TPH metadata
> + * @extended: false to request the 8-bit ST namespace, true to request
> + * the 16-bit Extended ST namespace
> + * @steering_tag: Returns the raw TPH steering tag for the requested
> + * namespace
> + * @ph: Returns the TPH processing hint (2-bit value)
> + *
> + * Return the TPH (TLP Processing Hints) metadata associated with this
> + * DMA buffer for the requested steering-tag namespace. 8-bit ST and
> + * 16-bit Extended ST are distinct namespaces in the PCIe TPH ST table
> + * and may both be present with different values, so the exporter must
> + * select the value that matches @extended and must not substitute one
> + * for the other.
> + *
> + * The exporter owns the completing address space for @dmabuf and
> + * therefore decides whether it can derive meaningful TPH metadata for
> + * that completer. The dma-buf core treats the returned ST/PH tuple as
> + * opaque transport metadata; importers that support TPH place it on
> + * outbound TLPs, while exporters that cannot derive a useful tuple
> + * simply return -EOPNOTSUPP.
> + *
> + * Return 0 on success, or -EOPNOTSUPP if no metadata is available for
> + * the requested namespace.
> + *
> + * This callback is optional.
> + */
> + int (*get_tph)(struct dma_buf *dmabuf, bool extended,
> + u16 *steering_tag, u8 *ph);
> +
That needs a wrapper for importers to call which also handles if the callback isn't present.
Regards,
Christian.
> /**
> * @map_dma_buf:
> *
next parent reply other threads:[~2026-06-09 8:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260608185646.4085127-1-zhipingz@meta.com>
[not found] ` <20260608185646.4085127-4-zhipingz@meta.com>
2026-06-09 8:10 ` Christian König [this message]
2026-06-09 14:38 ` [PATCH v6 3/5] dma-buf: add optional get_tph() callback Zhiping Zhang
[not found] ` <20260608185646.4085127-5-zhipingz@meta.com>
2026-06-09 8:12 ` [PATCH v6 4/5] vfio/pci: implement get_tph and DMA_BUF_TPH feature Christian König
2026-06-09 14:39 ` Zhiping Zhang
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=40243782-e4ff-435c-ae40-3ac1c7c4815e@amd.com \
--to=christian.koenig@amd.com \
--cc=alex@shazbot.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=helgaas@kernel.org \
--cc=jgg@ziepe.ca \
--cc=kbusch@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=leon@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=yishaih@nvidia.com \
--cc=yochai@nvidia.com \
--cc=zhipingz@meta.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