mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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



  reply	other threads:[~2026-11-15  7:59 UTC|newest]

Thread overview: 31+ 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-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

all inboxes | Powered by JetHome®