From: Ferruh Yigit <ferruh.yigit@intel.com>
To: "Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at Cisco)"
<jgrajcia@cisco.com>, Phil Yang <Phil.Yang@arm.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Ruifeng Wang <Ruifeng.Wang@arm.com>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH] net/memif: relax barrier for zero copy path
Date: Mon, 21 Sep 2020 14:27:32 +0100 [thread overview]
Message-ID: <7b2291ea-d680-e508-0802-f9337a43b172@intel.com> (raw)
In-Reply-To: <BYAPR11MB35742B06BE3699B4009B5D5DDF3A0@BYAPR11MB3574.namprd11.prod.outlook.com>
On 9/21/2020 1:21 PM, Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at
Cisco) wrote:
>>>>>
>>>>> Using 'rte_mb' to synchronize the shared ring head/tail between
>>>>> producer and consumer will stall the pipeline and damage
>>>>> performance on the weak memory model platforms, such like aarch64.
>>>>>
>>>>> Relax the expensive barrier with c11 atomic with explicit memory
>>>>> ordering can improve 3.6% performance on throughput.
>>>
>>> My question here is: `rte_mb` is supposed to make sure that head/tail
>>> pointer are not updated before the packets are written into shared
>> memory.
>>> Does the atomic ensures that the packets are written into shared
>>> memory before head/tail pointers are updated?
>>
>> Yes, it does.
>> The atomic store-release acts as a one-way barrier here to make sure all the
>> memory accesses before the store-release are observed before it.
>
> Ok then, since the sync is there and the rest seems fine to me.
>
> Thanks,
> Jakub
>
> Reviewed-by: Jakub Grajciar <jgrajcia@cisco.com>
>
Applied to dpdk-next-net/main, thanks.
next prev parent reply other threads:[~2020-09-21 13:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 5:38 [dpdk-dev] [PATCH] net/memif: relax barrier for zero copy path Phil Yang
2020-09-18 11:58 ` Ferruh Yigit
2020-09-18 22:49 ` Honnappa Nagarahalli
2020-09-21 9:03 ` Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at Cisco)
2020-09-21 10:22 ` Phil Yang
2020-09-21 12:21 ` Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at Cisco)
2020-09-21 13:27 ` Ferruh Yigit [this message]
2020-09-21 19:28 ` Honnappa Nagarahalli
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=7b2291ea-d680-e508-0802-f9337a43b172@intel.com \
--to=ferruh.yigit@intel.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Phil.Yang@arm.com \
--cc=Ruifeng.Wang@arm.com \
--cc=dev@dpdk.org \
--cc=jgrajcia@cisco.com \
--cc=nd@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.