Re: [PATCH net-next V2 2/2] net/mlx5e: SHAMPO, Improve allocation recovery

[Jacob Keller <jacob.e.keller@intel.com>]

On 2/2/2026 11:21 PM, Tariq Toukan wrote:
> From: Dragos Tatulea <dtatulea@nvidia.com>
> 
> When memory providers are used, there is a disconnect between the
> page_pool size and the available memory in the provider. This means
> that the page_pool can run out of memory if the user didn't provision
> a large enough buffer.
> 
> Under these conditions, mlx5 gets stuck trying to allocate new
> buffers without being able to release existing buffers. This happens due
> to the optimization introduced in commit 4c2a13236807
> ("net/mlx5e: RX, Defer page release in striding rq for better recycling")
> which delays WQE releases to increase the chance of page_pool direct
> recycling. The optimization was developed before memory providers
> existed and this circumstance was not considered.
> 
> This patch unblocks the queue by reclaiming pages from WQEs that can be
> freed and doing a one-shot retry. A WQE can be freed when:
> 1) All its strides have been consumed (WQE is no longer in linked list).
> 2) The WQE pages/netmems have not been previously released.
> 
> This reclaim mechanism is useful for regular pages as well.
> 
> Note that provisioning memory that can't fill even one MPWQE (64
> 4K pages) will still render the queue unusable. Same when
> the application doesn't release its buffers for various reasons.
> Or a combination of the two: a very small buffer is provisioned,
> application releases buffers in bulk, bulk size never reached
> => queue is stuck.
> 
> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> ---
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>