|SUCCESS| [v2] ring: add cache guard after ring elements table

[dpdklab at iol.unh.edu]

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

_AI Code Review_

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

git sha: 20260505161329.258182-1-mb at smartsharesystems.com
Author: Morten Brorup <mb at smartsharesystems.com>
Subject: [PATCH v2] ring: add cache guard after ring elements table

This patch adds a cache guard after the ring elements table to prevent
false sharing from hardware prefetchers.

> diff --git a/lib/ring/rte_ring.c b/lib/ring/rte_ring.c
> index f10050a1c4..10b52dc679 100644
> --- a/lib/ring/rte_ring.c
> +++ b/lib/ring/rte_ring.c
> @@ -73,8 +73,15 @@ rte_ring_get_memsize_elem(unsigned int esize, unsigned int count)
>  		return -EINVAL;
>  	}
>  
> +	static_assert(sizeof(struct rte_ring) == RTE_CACHE_LINE_ROUNDUP(sizeof(struct rte_ring)),
> +			"Size of struct rte_ring not cache line aligned");

Does this static_assert line exceed 100 characters? Lines should not
exceed 100 characters according to the coding style guide.

>  	sz = sizeof(struct rte_ring) + (ssize_t)count * esize;
> +	/* Add padding, to guard against false sharing-like effects
> +	 * on systems with a next-N-lines hardware prefetcher, when
> +	 * accessing elements at the end of the ring table.
> +	 */
>  	sz = RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> +	sz += RTE_CACHE_GUARD_LINES * RTE_CACHE_LINE_SIZE;

[ ... ]

Can this change affect the behavior of existing ring allocations where
callers rely on the previous memory size? Does increasing the allocation
size by RTE_CACHE_GUARD_LINES potentially break ABIs or cause unexpected
memory requirements in constrained environments?

Is RTE_CACHE_GUARD_LINES defined and documented? Does it have a sensible
default value if not defined by the user?