|SUCCESS| [v7] mempool/dpaa2: update for new mempool cache algorithm

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164748

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-06-01

Commit: [git sha not available from patch file]
Author: Morten Brorup <mb at smartsharesystems.com>
Subject: [PATCH v7] mempool/dpaa2: update for new mempool cache algorithm

This patch removes code that was modifying the mempool cache's
flushthresh field, which became obsolete due to improvements in the
mempool cache algorithm.

> diff --git a/drivers/mempool/dpaa2/dpaa2_hw_mempool.c b/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
> index 02b6741853..ee001d8ce0 100644
> --- a/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
> +++ b/drivers/mempool/dpaa2/dpaa2_hw_mempool.c
> @@ -54,8 +54,6 @@ rte_hw_mbuf_create_pool(struct rte_mempool *mp)
>  	struct dpaa2_bp_info *bp_info;
>  	struct dpbp_attr dpbp_attr;
>  	uint32_t bpid;
> -	unsigned int lcore_id;
> -	struct rte_mempool_cache *cache;
>  	int ret;
>  
>  	avail_dpbp = dpaa2_alloc_dpbp_dev();

[ ... ]

> @@ -152,18 +150,6 @@ rte_hw_mbuf_create_pool(struct rte_mempool *mp)
>  	DPAA2_MEMPOOL_DEBUG("BP List created for bpid =%d", dpbp_attr.bpid);
>  
>  	h_bp_list = bp_list;
> -	/* Update per core mempool cache threshold to optimal value which is
> -	 * number of buffers that can be released to HW buffer pool in
> -	 * a single API call.
> -	 */
> -	for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
> -		cache = &mp->local_cache[lcore_id];
> -		DPAA2_MEMPOOL_DEBUG("lCore %d: cache->flushthresh %d -> %d",
> -			lcore_id, cache->flushthresh,
> -			(uint32_t)(cache->size + DPAA2_MBUF_MAX_ACQ_REL));
> -		if (cache->flushthresh)
> -			cache->flushthresh = cache->size + DPAA2_MBUF_MAX_ACQ_REL;
> -	}

Does this removal break functionality for the dpaa2 mempool driver? The
removed code was tuning the cache->flushthresh based on the hardware's
DPAA2_MBUF_MAX_ACQ_REL constraint. If the new mempool cache algorithm
uses a different mechanism, does it account for this hardware-specific
limitation? Can the hardware still handle the cache flush sizes after
this change?

The commit message states that modifying flushthresh "has no effect" but
does not explain how the hardware constraint previously enforced by this
code is now satisfied. Is there documentation or testing that confirms
the dpaa2 hardware works correctly with the new algorithm?

>  
>  	return 0;
>  err4: