From: Tariq Toukan <tariqt@nvidia.com>
To: Dragos Tatulea <dtatulea@nvidia.com>,
Stanislav Fomichev <sdf.kernel@gmail.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: Sun, 15 Nov 2026 09:59:42 +0200 [thread overview]
Message-ID: <2cf34dbe-8965-4917-861f-b9306153f850@nvidia.com> (raw)
In-Reply-To: <ebd14110-49f4-4fbd-9dbe-1c39a1706da9@nvidia.com>
On 13/11/2026 17:00, Dragos Tatulea wrote:
> 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!
>
pw-bot: cr
next prev parent reply other threads:[~2026-11-15 7:59 UTC|newest]
Thread overview: 32+ 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
2026-11-15 7:59 ` Tariq Toukan [this message]
2026-11-12 9:40 ` netdev-bot+sashiko
2026-11-13 15:02 ` Dragos Tatulea
2026-11-15 18:17 ` Jakub Kicinski
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-14 9:54 ` Dragos Tatulea
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-14 9:54 ` Dragos Tatulea
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=2cf34dbe-8965-4917-861f-b9306153f850@nvidia.com \
--to=tariqt@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=dtatulea@nvidia.com \
--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=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