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

  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®