|SUCCESS| [v7] mempool/dpaa: update for new mempool cache algorithm
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Tue Jun 2 11:36:02 CEST 2026
Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164749
_AI Code Review_
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-06-02
sha: (not available - reviewing patch file)
Author: Morten Brorup <mb at smartsharesystems.com>
Subject: [PATCH v7] mempool/dpaa: update for new mempool cache algorithm
This patch removes code that was modifying the mempool cache's
flushthresh field, which has become obsolete due to a new mempool cache
algorithm.
> diff --git a/drivers/mempool/dpaa/dpaa_mempool.c b/drivers/mempool/dpaa/dpaa_mempool.c
> index 2f9395b3f4..2f8555a026 100644
> --- a/drivers/mempool/dpaa/dpaa_mempool.c
> +++ b/drivers/mempool/dpaa/dpaa_mempool.c
> @@ -58,8 +58,6 @@ dpaa_mbuf_create_pool(struct rte_mempool *mp)
> struct bman_pool_params params = {
> .flags = BMAN_POOL_FLAG_DYNAMIC_BPID
> };
> - unsigned int lcore_id;
> - struct rte_mempool_cache *cache;
>
> MEMPOOL_INIT_FUNC_TRACE();
>
[ ... ]
> @@ -129,18 +127,6 @@ dpaa_mbuf_create_pool(struct rte_mempool *mp)
> rte_memcpy(bp_info, (void *)&rte_dpaa_bpid_info[bpid],
> sizeof(struct dpaa_bp_info));
> mp->pool_data = (void *)bp_info;
> - /* 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];
> - DPAA_MEMPOOL_DEBUG("lCore %d: cache->flushthresh %d -> %d",
> - lcore_id, cache->flushthresh,
> - (uint32_t)(cache->size + DPAA_MBUF_MAX_ACQ_REL));
> - if (cache->flushthresh)
> - cache->flushthresh = cache->size + DPAA_MBUF_MAX_ACQ_REL;
> - }
>
> DPAA_MEMPOOL_DEBUG("BMAN pool created for bpid =%d", bpid);
> return 0;
Does the dpaa driver require any additional changes to work correctly with
the new mempool cache algorithm? The removed code suggests that this driver
had specific requirements about when buffers should be flushed back to the
hardware buffer pool. Since flushthresh is being removed, does the new
algorithm guarantee that the DPAA_MBUF_MAX_ACQ_REL constraint is still
respected when releasing buffers to the hardware?
Can the new cache algorithm handle the hardware-specific batching
requirements that the removed code was trying to enforce?
More information about the test-report
mailing list