[RFC net-next v3 0/7] devmem/io_uring: allow more flexibility for ZC DMA devices

[RFC net-next v3 0/7] devmem/io_uring: allow more flexibility for ZC DMA devices

[Dragos Tatulea]

For TCP zerocopy rx (io_uring, devmem), there is an assumption that the
parent device can do DMA. However that is not always the case:
- Scalable Function netdevs [1] have the DMA device in the grandparent.
- For Multi-PF netdevs [2] queues can be associated to different DMA
  devices.

The series adds an API for getting the DMA device for a netdev queue.
Drivers that have special requirements can implement the newly added
queue management op. Otherwise the parent will still be used as before.

This series continues with switching to this API for io_uring zcrx and
devmem and adds a ndo_queue_dma_dev op for mlx5.

The last part of the series changes devmem rx bind to get the DMA device
per queue and blocks the case when multiple queues use different DMA
devices. The tx bind is left as is.

[1] Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
[2] Documentation/networking/multi-pf-netdev.rst

Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>

----
Changes sice v2 [3]:
- Downgraded to RFC status until consensus is reached.
- Implemented more generic approach as discussed during
  v2 review.
- Refactor devmem to get DMA device for multiple rx queues for
  multi PF netdev support.
- Renamed series with a more generic name.

Changes since v1 [2]:
- Dropped the Fixes tag.
- Added more documentation as requeseted.
- Renamed the patch title to better reflect its purpose.

Changes since RFC [1]:
- Upgraded from RFC status.
- Dropped driver specific bits for generic solution.
- Implemented single patch as a fix as requested in RFC.
- Handling of multi-PF netdevs will be handled in a subsequent patch
  series.

[1] RFC: https://lore.kernel.org/all/20250702172433.1738947-2-dtatulea@nvidia.com/
[2]  v1: https://lore.kernel.org/all/20250709124059.516095-2-dtatulea@nvidia.com/
[3]  v2: https://lore.kernel.org/all/20250711092634.2733340-2-dtatulea@nvidia.com/
---
Dragos Tatulea (7):
  queue_api: add support for fetching per queue DMA dev
  io_uring/zcrx: add support for custom DMA devices
  net: devmem: get netdev DMA device via new API
  net/mlx5e: add op for getting netdev DMA device
  net: devmem: pull out dma_dev out of net_devmem_bind_dmabuf
  net: devmem: pre-read requested rx queues during bind
  net: devmem: allow binding on rx queues with same MA devices

 .../net/ethernet/mellanox/mlx5/core/en_main.c |  24 ++++
 include/net/netdev_queues.h                   |  20 ++++
 io_uring/zcrx.c                               |   3 +-
 net/core/devmem.c                             |   8 +-
 net/core/devmem.h                             |   2 +
 net/core/netdev-genl.c                        | 113 +++++++++++++-----
 6 files changed, 137 insertions(+), 33 deletions(-)

-- 
2.50.1

[RFC net-next v3 4/7] net/mlx5e: add op for getting netdev DMA device

[Dragos Tatulea]

For zero-copy (devmem, io_uring), the netdev DMA device used
is the parent device of the net device. However that is not
always accurate for mlx5 devices:
- SFs: The parent device is an auxdev.
- Multi-PF netdevs: The DMA device should be determined by
  the queue.

This change implements the DMA device queue API that returns the DMA
device appropriately for all cases.

Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
---
 .../net/ethernet/mellanox/mlx5/core/en_main.c | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 21bb88c5d3dc..0e48065a46eb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -5625,12 +5625,36 @@ static int mlx5e_queue_start(struct net_device *dev, void *newq,
 	return 0;
 }
 
+static struct device *mlx5e_queue_get_dma_dev(struct net_device *dev,
+					      int queue_index)
+{
+	struct mlx5e_priv *priv = netdev_priv(dev);
+	struct mlx5e_channels *channels;
+	struct device *pdev = NULL;
+	struct mlx5e_channel *ch;
+
+	channels = &priv->channels;
+
+	mutex_lock(&priv->state_lock);
+
+	if (queue_index >= channels->num)
+		goto out;
+
+	ch = channels->c[queue_index];
+	pdev = ch->pdev;
+out:
+	mutex_unlock(&priv->state_lock);
+
+	return pdev;
+}
+
 static const struct netdev_queue_mgmt_ops mlx5e_queue_mgmt_ops = {
 	.ndo_queue_mem_size	=	sizeof(struct mlx5_qmgmt_data),
 	.ndo_queue_mem_alloc	=	mlx5e_queue_mem_alloc,
 	.ndo_queue_mem_free	=	mlx5e_queue_mem_free,
 	.ndo_queue_start	=	mlx5e_queue_start,
 	.ndo_queue_stop		=	mlx5e_queue_stop,
+	.ndo_queue_get_dma_dev	=	mlx5e_queue_get_dma_dev,
 };
 
 static void mlx5e_build_nic_netdev(struct net_device *netdev)
-- 
2.50.1

Re: [RFC net-next v3 0/7] devmem/io_uring: allow more flexibility for ZC DMA devices

[Stanislav Fomichev]

On 08/15, Dragos Tatulea wrote:
> For TCP zerocopy rx (io_uring, devmem), there is an assumption that the
> parent device can do DMA. However that is not always the case:
> - Scalable Function netdevs [1] have the DMA device in the grandparent.
> - For Multi-PF netdevs [2] queues can be associated to different DMA
>   devices.
> 
> The series adds an API for getting the DMA device for a netdev queue.
> Drivers that have special requirements can implement the newly added
> queue management op. Otherwise the parent will still be used as before.
> 
> This series continues with switching to this API for io_uring zcrx and
> devmem and adds a ndo_queue_dma_dev op for mlx5.
> 
> The last part of the series changes devmem rx bind to get the DMA device
> per queue and blocks the case when multiple queues use different DMA
> devices. The tx bind is left as is.
> 
> [1] Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
> [2] Documentation/networking/multi-pf-netdev.rst
> 
> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> 
> ----
> Changes sice v2 [3]:
> - Downgraded to RFC status until consensus is reached.
> - Implemented more generic approach as discussed during
>   v2 review.
> - Refactor devmem to get DMA device for multiple rx queues for
>   multi PF netdev support.
> - Renamed series with a more generic name.
> 
> Changes since v1 [2]:
> - Dropped the Fixes tag.
> - Added more documentation as requeseted.
> - Renamed the patch title to better reflect its purpose.
> 
> Changes since RFC [1]:
> - Upgraded from RFC status.
> - Dropped driver specific bits for generic solution.
> - Implemented single patch as a fix as requested in RFC.
> - Handling of multi-PF netdevs will be handled in a subsequent patch
>   series.
> 
> [1] RFC: https://lore.kernel.org/all/20250702172433.1738947-2-dtatulea@nvidia.com/
> [2]  v1: https://lore.kernel.org/all/20250709124059.516095-2-dtatulea@nvidia.com/
> [3]  v2: https://lore.kernel.org/all/20250711092634.2733340-2-dtatulea@nvidia.com/
> ---
> Dragos Tatulea (7):
>   queue_api: add support for fetching per queue DMA dev

[..]

>   io_uring/zcrx: add support for custom DMA devices

Did something happen to 2/7? I don't see it in my mailbox and in the
lore..

Re: [RFC net-next v3 0/7] devmem/io_uring: allow more flexibility for ZC DMA devices

[Dragos Tatulea]

On Fri, Aug 15, 2025 at 08:31:05AM -0700, Stanislav Fomichev wrote:
> On 08/15, Dragos Tatulea wrote:
> > For TCP zerocopy rx (io_uring, devmem), there is an assumption that the
> > parent device can do DMA. However that is not always the case:
> > - Scalable Function netdevs [1] have the DMA device in the grandparent.
> > - For Multi-PF netdevs [2] queues can be associated to different DMA
> >   devices.
> > 
> > The series adds an API for getting the DMA device for a netdev queue.
> > Drivers that have special requirements can implement the newly added
> > queue management op. Otherwise the parent will still be used as before.
> > 
> > This series continues with switching to this API for io_uring zcrx and
> > devmem and adds a ndo_queue_dma_dev op for mlx5.
> > 
> > The last part of the series changes devmem rx bind to get the DMA device
> > per queue and blocks the case when multiple queues use different DMA
> > devices. The tx bind is left as is.
> > 
> > [1] Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst
> > [2] Documentation/networking/multi-pf-netdev.rst
> > 
> > Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> > 
> > ----
> > Changes sice v2 [3]:
> > - Downgraded to RFC status until consensus is reached.
> > - Implemented more generic approach as discussed during
> >   v2 review.
> > - Refactor devmem to get DMA device for multiple rx queues for
> >   multi PF netdev support.
> > - Renamed series with a more generic name.
> > 
> > Changes since v1 [2]:
> > - Dropped the Fixes tag.
> > - Added more documentation as requeseted.
> > - Renamed the patch title to better reflect its purpose.
> > 
> > Changes since RFC [1]:
> > - Upgraded from RFC status.
> > - Dropped driver specific bits for generic solution.
> > - Implemented single patch as a fix as requested in RFC.
> > - Handling of multi-PF netdevs will be handled in a subsequent patch
> >   series.
> > 
> > [1] RFC: https://lore.kernel.org/all/20250702172433.1738947-2-dtatulea@nvidia.com/
> > [2]  v1: https://lore.kernel.org/all/20250709124059.516095-2-dtatulea@nvidia.com/
> > [3]  v2: https://lore.kernel.org/all/20250711092634.2733340-2-dtatulea@nvidia.com/
> > ---
> > Dragos Tatulea (7):
> >   queue_api: add support for fetching per queue DMA dev
> 
> [..]
> 
> >   io_uring/zcrx: add support for custom DMA devices
> 
> Did something happen to 2/7? I don't see it in my mailbox and in the
> lore..
I see it in lore:
https://lore.kernel.org/all/20250815110401.2254214-4-dtatulea@nvidia.com

But it seems to have been sent to io-uring ml only and since you were
not CC'ed, I guess it never reached your inbox... I should have
explicitly CC'ed netdev instead of relying on get_maintainers.pl. Will
do it next time.

Thanks,
Dragos

Re: [RFC net-next v3 4/7] net/mlx5e: add op for getting netdev DMA device

[Mina Almasry]

On Fri, Aug 15, 2025 at 4:07 AM Dragos Tatulea <dtatulea@nvidia.com> wrote:
>
> For zero-copy (devmem, io_uring), the netdev DMA device used
> is the parent device of the net device. However that is not
> always accurate for mlx5 devices:
> - SFs: The parent device is an auxdev.
> - Multi-PF netdevs: The DMA device should be determined by
>   the queue.
>
> This change implements the DMA device queue API that returns the DMA
> device appropriately for all cases.
>
> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> ---
>  .../net/ethernet/mellanox/mlx5/core/en_main.c | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 21bb88c5d3dc..0e48065a46eb 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -5625,12 +5625,36 @@ static int mlx5e_queue_start(struct net_device *dev, void *newq,
>         return 0;
>  }
>
> +static struct device *mlx5e_queue_get_dma_dev(struct net_device *dev,
> +                                             int queue_index)
> +{
> +       struct mlx5e_priv *priv = netdev_priv(dev);
> +       struct mlx5e_channels *channels;
> +       struct device *pdev = NULL;
> +       struct mlx5e_channel *ch;
> +
> +       channels = &priv->channels;
> +
> +       mutex_lock(&priv->state_lock);
> +
> +       if (queue_index >= channels->num)
> +               goto out;
> +
> +       ch = channels->c[queue_index];
> +       pdev = ch->pdev;

This code assumes priv is initialized, and probably that the device is
up/running/registered. At first I thought that was fine, but now that
I look at the code more closely, netdev_nl_bind_rx_doit checks if the
device is present but doesn't seem to check that the device is
registered.

I wonder if we should have a generic check in netdev_nl_bind_rx_doit
for NETDEV_REGISTERED, and if not, does this code handle unregistered
netdev correctly (like netdev_priv and priv->channels are valid even
for unregistered mlx5 devices)?


-- 
Thanks,
Mina

Re: [RFC net-next v3 4/7] net/mlx5e: add op for getting netdev DMA device

[Dragos Tatulea]

On Fri, Aug 15, 2025 at 10:37:15AM -0700, Mina Almasry wrote:
> On Fri, Aug 15, 2025 at 4:07 AM Dragos Tatulea <dtatulea@nvidia.com> wrote:
> >
> > For zero-copy (devmem, io_uring), the netdev DMA device used
> > is the parent device of the net device. However that is not
> > always accurate for mlx5 devices:
> > - SFs: The parent device is an auxdev.
> > - Multi-PF netdevs: The DMA device should be determined by
> >   the queue.
> >
> > This change implements the DMA device queue API that returns the DMA
> > device appropriately for all cases.
> >
> > Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> > ---
> >  .../net/ethernet/mellanox/mlx5/core/en_main.c | 24 +++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > index 21bb88c5d3dc..0e48065a46eb 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > @@ -5625,12 +5625,36 @@ static int mlx5e_queue_start(struct net_device *dev, void *newq,
> >         return 0;
> >  }
> >
> > +static struct device *mlx5e_queue_get_dma_dev(struct net_device *dev,
> > +                                             int queue_index)
> > +{
> > +       struct mlx5e_priv *priv = netdev_priv(dev);
> > +       struct mlx5e_channels *channels;
> > +       struct device *pdev = NULL;
> > +       struct mlx5e_channel *ch;
> > +
> > +       channels = &priv->channels;
> > +
> > +       mutex_lock(&priv->state_lock);
> > +
> > +       if (queue_index >= channels->num)
> > +               goto out;
> > +
> > +       ch = channels->c[queue_index];
> > +       pdev = ch->pdev;
> 
> This code assumes priv is initialized, and probably that the device is
> up/running/registered. At first I thought that was fine, but now that
> I look at the code more closely, netdev_nl_bind_rx_doit checks if the
> device is present but doesn't seem to check that the device is
> registered.
> 
> I wonder if we should have a generic check in netdev_nl_bind_rx_doit
> for NETDEV_REGISTERED, and if not, does this code handle unregistered
> netdev correctly (like netdev_priv and priv->channels are valid even
> for unregistered mlx5 devices)?
>
netdev_get_by_index_lock() returns non-NULL only when the device is in
state NETDEV_REGISTERED or NETREG_UNINITIALIZED. So I think  that this
check should suffice.

Thanks,
Dragos

Re: [RFC net-next v3 4/7] net/mlx5e: add op for getting netdev DMA device

[Mina Almasry]

On Mon, Aug 18, 2025 at 10:40 AM Dragos Tatulea <dtatulea@nvidia.com> wrote:
>
> On Fri, Aug 15, 2025 at 10:37:15AM -0700, Mina Almasry wrote:
> > On Fri, Aug 15, 2025 at 4:07 AM Dragos Tatulea <dtatulea@nvidia.com> wrote:
> > >
> > > For zero-copy (devmem, io_uring), the netdev DMA device used
> > > is the parent device of the net device. However that is not
> > > always accurate for mlx5 devices:
> > > - SFs: The parent device is an auxdev.
> > > - Multi-PF netdevs: The DMA device should be determined by
> > >   the queue.
> > >
> > > This change implements the DMA device queue API that returns the DMA
> > > device appropriately for all cases.
> > >
> > > Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> > > ---
> > >  .../net/ethernet/mellanox/mlx5/core/en_main.c | 24 +++++++++++++++++++
> > >  1 file changed, 24 insertions(+)
> > >
> > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > > index 21bb88c5d3dc..0e48065a46eb 100644
> > > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> > > @@ -5625,12 +5625,36 @@ static int mlx5e_queue_start(struct net_device *dev, void *newq,
> > >         return 0;
> > >  }
> > >
> > > +static struct device *mlx5e_queue_get_dma_dev(struct net_device *dev,
> > > +                                             int queue_index)
> > > +{
> > > +       struct mlx5e_priv *priv = netdev_priv(dev);
> > > +       struct mlx5e_channels *channels;
> > > +       struct device *pdev = NULL;
> > > +       struct mlx5e_channel *ch;
> > > +
> > > +       channels = &priv->channels;
> > > +
> > > +       mutex_lock(&priv->state_lock);
> > > +
> > > +       if (queue_index >= channels->num)
> > > +               goto out;
> > > +
> > > +       ch = channels->c[queue_index];
> > > +       pdev = ch->pdev;
> >
> > This code assumes priv is initialized, and probably that the device is
> > up/running/registered. At first I thought that was fine, but now that
> > I look at the code more closely, netdev_nl_bind_rx_doit checks if the
> > device is present but doesn't seem to check that the device is
> > registered.
> >
> > I wonder if we should have a generic check in netdev_nl_bind_rx_doit
> > for NETDEV_REGISTERED, and if not, does this code handle unregistered
> > netdev correctly (like netdev_priv and priv->channels are valid even
> > for unregistered mlx5 devices)?
> >
> netdev_get_by_index_lock() returns non-NULL only when the device is in
> state NETDEV_REGISTERED or NETREG_UNINITIALIZED. So I think  that this
> check should suffice.
>

Ack, thanks for checking. For the patch:

Reviewed-by: Mina Almasry <almasrymina@google.com>



-- 
Thanks,
Mina