Re: [PATCH net-next 3/3] net/mlx5: use internal dma pools for frag buf alloc

[Leon Romanovsky]

On Tue, Apr 28, 2026 at 08:29:20AM +0300, Tariq Toukan wrote:
> From: Nimrod Oren <noren@xxxxxxxxxx>
> 
> Add mlx5_dma_pool alloc/free paths, and wire mlx5_frag_buf allocation
> and free paths to use them.
> 
> mlx5_frag_buf_alloc_node() now selects an mlx5_dma_pool to allocate
> fragments from, instead of directly allocating full coherent pages.
> 
> mlx5_frag_buf_free() frees from the respective pool.
> 
> mlx5_dma_pool_alloc() keeps allocation fast by maintaining pages with
> available indexes at the head of the list, so the common allocation path
> can take a free index immediately. New backing pages are allocated only
> when no free index is available.
> 
> mlx5_dma_pool_free() returns released indexes to the pool and frees a
> backing page once all of its indexes become free. This avoids keeping
> fully free pages for the lifetime of the pool and reduces coherent DMA
> memory footprint.
> 
> Signed-off-by: Nimrod Oren <noren@xxxxxxxxxx>
> Signed-off-by: Tariq Toukan <tariqt@xxxxxxxxxx>
> ---
>  .../net/ethernet/mellanox/mlx5/core/alloc.c   | 185 ++++++++++++++----
>  include/linux/mlx5/driver.h                   |   2 +
>  2 files changed, 154 insertions(+), 33 deletions(-)

<...>

> +	if (WARN_ONCE(idx >= blocks_per_page,
> +		      "mlx5 dma pool invalid idx: %lu (max %d)\n",
> +		      idx, blocks_per_page - 1))
> +		return;

<...>

> +	if (WARN_ONCE(test_bit(idx, page->bitmap),
> +		      "mlx5 dma pool double free: idx=%lu block_shift=%u\n",
> +		      idx, pool->block_shift))
> +		goto unlock;

<...>

> +	if (WARN_ONCE(size <= 0, "mlx5_frag_buf non-positive size: %d\n", size))
> +		return -EINVAL;

<...>

> +	if (WARN_ONCE(node < 0 || node >= nr_node_ids || !node_possible(node),
> +		      "mlx5_frag_buf invalid node ID: %d\n", node))
> +		return -EINVAL;

All WARN_ONCE() instances in this patch and the previous one are not
reachable. WARN_ONCE() should be used to detect states that are truly
impossible, not cases where the internal API is being misused.

There is no need for defensive programming when dealing with
in-kernel or in-driver APIs.

Thanks