From: Dragos Tatulea <dtatulea@nvidia.com>
To: Stanislav Fomichev <sdf.kernel@gmail.com>,
Tariq Toukan <tariqt@nvidia.com>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Bobby Eshleman <bobbyeshleman@meta.com>,
Carolina Jubran <cjubran@nvidia.com>,
Cosmin Ratiu <cratiu@nvidia.com>,
Daniel Borkmann <daniel@iogearbox.net>,
David Wei <dw@davidwei.uk>, Erfan Sharafzadeh <erfansh@meta.com>,
Gal Pressman <gal@nvidia.com>,
Jacob Keller <Jacob.e.keller@intel.com>,
Kaifeng Wang <kaifengw@google.com>,
Leon Romanovsky <leon@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
linux-rdma@vger.kernel.org, Mark Bloch <mbloch@nvidia.com>,
Matt Fleming <mfleming@cloudflare.com>,
Mina Almasry <almasrymina@google.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Saeed Mahameed <saeedm@nvidia.com>,
Simon Horman <horms@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>,
William Tu <witu@nvidia.com>,
Bobby Eshleman <bobbyeshleman@gmail.com>
Subject: Re: [PATCH net-next V2 10/13] net: devmem: add netdev_has_dmabuf_binding() helper
Date: Fri, 13 Nov 2026 17:00:28 +0200 [thread overview]
Message-ID: <ebd14110-49f4-4fbd-9dbe-1c39a1706da9@nvidia.com> (raw)
In-Reply-To: <avTdfAaW9tlBRM34@devvm16445.scu0.facebook.com>
On 11.11.26 22:46, Stanislav Fomichev wrote:
> On 11/10, Tariq Toukan wrote:
>> From: Dragos Tatulea <dtatulea@nvidia.com>
>>
>> Currently there is no way to check whether a dmabuf is bound on a TX
>> queue. RX side has netif_rxq_has_unreadable_mp() which gives a hint
>> of it.
>>
>> To help with that, add a helper to check whether a devmem dmabuf
>> binding may still be in use on a given netdev, optionally filtered by
>> the DMA device the dmabuf was mapped against.
>>
>> A binding can outlive the user's unbind: it can still be referenced by
>> in-flight TX skbs, whose DMA mappings are only valid for the device the
>> dmabuf was attached to. Reporting such a binding as gone would let a
>> driver swap the DMA device out from under those skbs. Bindings stay in
>> the bindings xarray until they are freed, so walk it and report every
>> binding of the netdev that is still mapped. Bindings that were already
>> unmapped are not reported.
>>
>> This API is necessary for the upcoming support of data direct in mlx5e.
>>
>> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
>> Cc: Bobby Eshleman <bobbyeshleman@gmail.com>
>> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
>> ---
>> include/net/netmem.h | 24 ++++++++++++++++++++++++
>> net/core/devmem.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 67 insertions(+)
>>
>> diff --git a/include/net/netmem.h b/include/net/netmem.h
>> index fb693bc1702a..35bb6fa0f719 100644
>> --- a/include/net/netmem.h
>> +++ b/include/net/netmem.h
>> @@ -397,16 +397,40 @@ static inline unsigned long netmem_get_dma_addr(netmem_ref netmem)
>> return netmem_to_nmdesc(netmem)->dma_addr;
>> }
>>
>> +struct net_device;
>> +
>> #if defined(CONFIG_NET_DEVMEM)
>> static inline bool net_is_devmem_iov(const struct net_iov *niov)
>> {
>> return niov->type == NET_IOV_DMABUF;
>> }
>> +
>> +/**
>> + * netdev_has_dmabuf_binding - is there a dmabuf binding for a
>> + * given @dev and @dma_dev
>> + *
>> + * @dev: netdev to check bindings
>> + * @dma_dev: dma device to check, when NULL it will not be checked
>> + *
>> + * A binding is reported for as long as it is mapped, which can be long
>> + * after the user unbound it: net_iovs of a TX binding can still be queued
>> + * in flight, with DMA mappings that are only valid for the device the dmabuf
>> + * was attached to.
>> + *
>> + * Return: true if a binding is found under @dev and possibly @dma_dev
>> + */
>> +bool netdev_has_dmabuf_binding(struct net_device *dev, struct device *dma_dev);
>> #else
>> static inline bool net_is_devmem_iov(const struct net_iov *niov)
>> {
>> return false;
>> }
>> +
>> +static inline bool netdev_has_dmabuf_binding(struct net_device *dev,
>> + struct device *dma_dev)
>> +{
>> + return false;
>> +}
>> #endif
>>
>> void net_iov_inc_ref(struct net_iov *niov);
>> diff --git a/net/core/devmem.c b/net/core/devmem.c
>> index 5c7d9640e9d1..dd3987bbd9f6 100644
>> --- a/net/core/devmem.c
>> +++ b/net/core/devmem.c
>> @@ -513,6 +513,49 @@ struct net_devmem_dmabuf_binding *net_devmem_lookup_dmabuf(u32 id)
>> return binding;
>> }
>>
>> +/* The attachment is cleared once the binding has been unmapped. */
>> +static bool
>> +net_devmem_binding_mapped_to(struct net_devmem_dmabuf_binding *binding,
>> + struct device *dma_dev)
>> +{
>> + lockdep_assert_held(&binding->lock);
>> +
>> + return binding->attachment &&
>> + (!dma_dev || binding->attachment->dev == dma_dev);
>> +}
>> +
>> +bool netdev_has_dmabuf_binding(struct net_device *dev, struct device *dma_dev)
>> +{
>> + struct net_devmem_dmabuf_binding *binding;
>> + unsigned long xa_idx;
>> + bool found = false;
>> +
>> + netdev_assert_locked(dev);
>> +
>> + /* A binding stays in the xarray until it is freed. binding->dev is
>> + * only cleared under the instance lock of that netdev, and the free
>> + * takes it before erasing the binding, so a binding found under @dev
>> + * stays alive while the xarray lock is dropped.
>> + */
>> + xa_lock(&net_devmem_dmabuf_bindings);
>> + xa_for_each(&net_devmem_dmabuf_bindings, xa_idx, binding) {
>> + if (READ_ONCE(binding->dev) != dev)
>> + continue;
>> +
>> + xa_unlock(&net_devmem_dmabuf_bindings);
>> + mutex_lock(&binding->lock);
>> + found = net_devmem_binding_mapped_to(binding, dma_dev);
>> + mutex_unlock(&binding->lock);
>> + xa_lock(&net_devmem_dmabuf_bindings);
>
> Sorry, my cache is already empty after c4466d2c3e77.. I wonder if it would
> be easier to change kfree(binding) to kfree_rcu(binding, ...) and then
> we can rcu_lock/xa_for_each here without xa_lock/mutex? All we care is our
> netdev bindings, and these are not being changed as long as we
> hold the instance lock (but the other ones are now concurrently freed,
> hence rcu so we can safely do READ_ONCE on the binding)..
>
> And then the same applies to path 11?
>
> (trying to keep all the complexity in net_devmem_dev_unregister)
Done. Will be part of v3. Code does look cleaner now for both patches.
Thanks for the suggestion!
Thanks,
Dragos
next prev parent reply other threads:[~2026-11-13 15:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 18:38 [PATCH net-next V2 00/13] net/mlx5e: Add netdev support for data direct Tariq Toukan
2026-11-10 18:38 ` [PATCH net-next V2 01/13] net/mlx5: Log the data direct to PF device mapping Tariq Toukan
2026-11-10 18:38 ` [PATCH net-next V2 02/13] net/mlx5: Detach auxiliary devices on attach failure during load Tariq Toukan
2026-11-12 9:40 ` netdev-bot+sashiko
2026-11-13 13:58 ` Dragos Tatulea
2026-11-10 18:38 ` [PATCH net-next V2 03/13] net/mlx5e: Register supported netdevs as data direct users Tariq Toukan
2026-11-10 18:38 ` [PATCH net-next V2 04/13] net/mlx5e: Pre-calculate UMR padding and entry size Tariq Toukan
2026-11-10 18:38 ` [PATCH net-next V2 05/13] net/mlx5e: Add data direct ethtool private flag Tariq Toukan
2026-11-10 18:38 ` [PATCH net-next V2 06/13] net/mlx5e: Add data direct RX infrastructure Tariq Toukan
2026-11-12 9:40 ` netdev-bot+sashiko
2026-11-13 14:28 ` Dragos Tatulea
2026-11-10 18:38 ` [PATCH net-next V2 07/13] net/mlx5e: SHAMPO, Use page_pool DMA sync helper for SKB frags Tariq Toukan
2026-11-12 9:40 ` netdev-bot+sashiko
2026-11-13 14:36 ` Dragos Tatulea
2026-11-10 18:38 ` [PATCH net-next V2 08/13] net/mlx5e: Add data direct TX infrastructure Tariq Toukan
2026-11-10 18:38 ` [PATCH net-next V2 09/13] net/mlx5e: Use the correct DMA dev when data_direct is enabled Tariq Toukan
2026-11-12 9:40 ` netdev-bot+sashiko
2026-11-13 14:43 ` Dragos Tatulea
2026-11-10 18:38 ` [PATCH net-next V2 10/13] net: devmem: add netdev_has_dmabuf_binding() helper Tariq Toukan
2026-11-11 21:46 ` Stanislav Fomichev
2026-11-13 15:00 ` Dragos Tatulea [this message]
2026-11-12 9:40 ` netdev-bot+sashiko
2026-11-13 15:02 ` Dragos Tatulea
2026-11-10 18:38 ` [PATCH net-next V2 11/13] net: add netdev_unbind_dma_dev() helper Tariq Toukan
2026-11-12 9:40 ` netdev-bot+sashiko
2026-11-10 18:38 ` [PATCH net-next V2 12/13] net/mlx5e: Disable data direct on data direct device unbind Tariq Toukan
2026-11-12 9:40 ` netdev-bot+sashiko
2026-11-10 18:38 ` [PATCH net-next V2 13/13] net/mlx5e: Enable the data direct netdev feature Tariq Toukan
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=ebd14110-49f4-4fbd-9dbe-1c39a1706da9@nvidia.com \
--to=dtatulea@nvidia.com \
--cc=Jacob.e.keller@intel.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=bobbyeshleman@gmail.com \
--cc=bobbyeshleman@meta.com \
--cc=cjubran@nvidia.com \
--cc=cratiu@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dw@davidwei.uk \
--cc=edumazet@kernel.org \
--cc=erfansh@meta.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=kaifengw@google.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=mfleming@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=saeedm@nvidia.com \
--cc=sdf.kernel@gmail.com \
--cc=sdf@fomichev.me \
--cc=tariqt@nvidia.com \
--cc=witu@nvidia.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
all inboxes | Powered by JetHome®