DPDK patches and discussions
 help / color / mirror / Atom feed
From: Wathsala Vithanage <wathsala.vithanage@arm.com>
To: Konstantin Ananyev <konstantin.ananyev@huawei.com>,
	Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Ola Liljedahl <ola.liljedahl@arm.com>,
	Dhruv Tripathi <dhruv.tripathi@arm.com>
Subject: Re: [PATCH v2 1/1] ring: safe partial ordering for head/tail update
Date: Mon, 13 Oct 2025 13:09:48 -0500	[thread overview]
Message-ID: <566b4c6c-f081-4db8-bc8b-2a576a82e1c3@arm.com> (raw)
In-Reply-To: <cfc073b8137541f1be3e01650d6bcf14@huawei.com>


On 10/8/25 03:00, Konstantin Ananyev wrote:
>
>> The function __rte_ring_headtail_move_head() assumes that the barrier
>> (fence) between the load of the head and the load-acquire of the
>> opposing tail guarantees the following: if a first thread reads tail
>> and then writes head and a second thread reads the new value of head
>> and then reads tail, then it should observe the same (or a later)
>> value of tail.
>>
>> This assumption is incorrect under the C11 memory model. If the barrier
>> (fence) is intended to establish a total ordering of ring operations,
>> it fails to do so. Instead, the current implementation only enforces a
>> partial ordering, which can lead to unsafe interleavings. In particular,
>> some partial orders can cause underflows in free slot or available
>> element computations, potentially resulting in data corruption.
>>
>> The issue manifests when a CPU first acts as a producer and later as a
>> consumer. In this scenario, the barrier assumption may fail when another
>> core takes the consumer role. A Herd7 litmus test in C11 can demonstrate
>> this violation. The problem has not been widely observed so far because:
>>    (a) on strong memory models (e.g., x86-64) the assumption holds, and
>>    (b) on relaxed models with RCsc semantics the ordering is still strong
>>        enough to prevent hazards.
>> The problem becomes visible only on weaker models, when load-acquire is
>> implemented with RCpc semantics (e.g. some AArch64 CPUs which support
>> the LDAPR and LDAPUR instructions).
>>
>> Three possible solutions exist:
>>    1. Strengthen ordering by upgrading release/acquire semantics to
>>       sequential consistency. This requires using seq-cst for stores,
>>       loads, and CAS operations. However, this approach introduces a
>>       significant performance penalty on relaxed-memory architectures.
>>
>>    2. Establish a safe partial order by enforcing a pair-wise
>>       happens-before relationship between thread of same role by changing
>>       the CAS and the preceding load of the head by converting them to
>>       release and acquire respectively. This approach makes the original
>>       barrier assumption unnecessary and allows its removal.
>>
>>    3. Retain partial ordering but ensure only safe partial orders are
>>       committed. This can be done by detecting underflow conditions
>>       (producer < consumer) and quashing the update in such cases.
>>       This approach makes the original barrier assumption unnecessary
>>       and allows its removal.
>>
>> This patch implements solution (2) to preserve the “enqueue always
>> succeeds” contract expected by dependent libraries (e.g., mempool).
>> While solution (3) offers higher performance, adopting it now would
>> break that assumption.
>>
>> Signed-off-by: Wathsala Vithanage <wathsala.vithanage@arm.com>
>> Signed-off-by: Ola Liljedahl <ola.liljedahl@arm.com>
>> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
>> Reviewed-by: Dhruv Tripathi <dhruv.tripathi@arm.com>
>> ---
>>   lib/ring/rte_ring_c11_pvt.h | 9 +++------
>>   1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/lib/ring/rte_ring_c11_pvt.h b/lib/ring/rte_ring_c11_pvt.h
>> index b9388af0da..98c6584edb 100644
>> --- a/lib/ring/rte_ring_c11_pvt.h
>> +++ b/lib/ring/rte_ring_c11_pvt.h
>> @@ -78,14 +78,11 @@ __rte_ring_headtail_move_head(struct rte_ring_headtail
>> *d,
>>   	unsigned int max = n;
>>
>>   	*old_head = rte_atomic_load_explicit(&d->head,
>> -			rte_memory_order_relaxed);
>> +			rte_memory_order_acquire);
>>   	do {
>>   		/* Reset n to the initial burst count */
>>   		n = max;
>>
>> -		/* Ensure the head is read before tail */
>> -		rte_atomic_thread_fence(rte_memory_order_acquire);
>> -
>>   		/* load-acquire synchronize with store-release of ht->tail
>>   		 * in update_tail.
>>   		 */
>> @@ -115,8 +112,8 @@ __rte_ring_headtail_move_head(struct rte_ring_headtail
>> *d,
>>   			/* on failure, *old_head is updated */
>>   			success =
>> rte_atomic_compare_exchange_strong_explicit(
>>   					&d->head, old_head, *new_head,
>> -					rte_memory_order_relaxed,
>> -					rte_memory_order_relaxed);
>> +					rte_memory_order_acq_rel,
>> +					rte_memory_order_acquire);
>>   	} while (unlikely(success == 0));
>>   	return n;
>>   }
>> --
> LGTM, though. I think that we also need to make similar changes in
> rte_ring_hts_elem_pvt.h and rte_ring_rts_elem_pvt.h:
> for CAS use 'acq_rel' order instead of simple 'acquire'.
> Let me know would you have a bandwidth to do that.

My bad, I forgot those two cases. I will send a v3.

-- wathsala

>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> Tested-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
>
>> 2.43.0
>>

      reply	other threads:[~2025-10-13 18:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-02 17:41 [PATCH v2 0/1] ring: correct ordering issue in " Wathsala Vithanage
2025-10-02 17:41 ` [PATCH v2 1/1] ring: safe partial ordering for " Wathsala Vithanage
2025-10-08  8:00   ` Konstantin Ananyev
2025-10-13 18:09     ` Wathsala Vithanage [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566b4c6c-f081-4db8-bc8b-2a576a82e1c3@arm.com \
    --to=wathsala.vithanage@arm.com \
    --cc=dev@dpdk.org \
    --cc=dhruv.tripathi@arm.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=konstantin.ananyev@huawei.com \
    --cc=ola.liljedahl@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).