From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"thomas@monjalon.net" <thomas@monjalon.net>,
"david.marchand@redhat.com" <david.marchand@redhat.com>
Cc: Song Zhu <Song.Zhu@arm.com>, Gavin Hu <Gavin.Hu@arm.com>,
Jeff Brownlee <Jeff.Brownlee@arm.com>,
Philippe Robin <Philippe.Robin@arm.com>,
Pravin Kantak <Pravin.Kantak@arm.com>, nd <nd@arm.com>,
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
nd <nd@arm.com>
Subject: Re: [dpdk-dev] Arm roadmap for 20.05
Date: Mon, 23 Mar 2020 17:12:32 +0000 [thread overview]
Message-ID: <VE1PR08MB514926E6CA8EF66A2EE139F198F00@VE1PR08MB5149.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <1f402872-6e8c-3fdc-1db4-e245efc6bfb5@ericsson.com>
<snip>
> >
> >> Subject: Re: [dpdk-dev] Arm roadmap for 20.05
> >>
> >> On 2020-03-10 17:42, Honnappa Nagarahalli wrote:
> >>> Hello,
> >>> Following are the work items planned for 20.05:
> >>>
> >>> 1) Use C11 atomic APIs in timer library
> >>> 2) Use C11 atomic APIs in service cores
> >>> 3) Use C11 atomics in VirtIO split ring
> >>> 4) Performance optimizations in i40e and MLX drivers for Arm
> >>> platforms
> >>> 5) RCU defer API
> >>> 6) Enable Travis CI with no huge-page tests - ~25 test cases
> >>>
> >>> Thank you,
> >>> Honnappa
> >> Maybe you should have a look at legacy DPDK atomics as well? Avoiding
> >> a full barrier for the add operation, for example.
> > By legacy, I believe you meant rte_atomic APIs. Those APIs do not take
> memory order as a parameter. So, it is difficult to change the implementation
> for those APIs. For ex: the add operation could take a RELEASE or RELAXED
> order depending on the use case.
> > So, the proposal is to deprecate the rte_atomic APIs and use C11 APIs
> > directly. The proposal is here:
> > https://protect2.fireeye.com/v1/url?k=2e04311e-72d039b7-2e047185-
> 865b3
> > b1e120b-91a0698f69ff0d1f&q=1&e=976056f3-f089-4fa8-86b2-
> aa5e88331555&u=
> > https%3A%2F%2Fpatches.dpdk.org%2Fcover%2F66745%2F
>
> Even though rte_atomic lacks the flexibility of C11 atomics, there might still be
> areas of improvement. Such improvements will have an instant effect, as
> opposed to waiting for all the rte_atomic users to change.
>
>
> The rte_atomic API leaves ordering unspecified, unfortunately. In the Linux
> kernel, from which DPDK seems to borrow much of the atomics and memory
> order related semantics, an atomic add doesn't imply any memory barriers.
> The current __sync_fetch_and_add()-based implementation implies a full
> barrier (ldadd+dmb) or release (ldaddal, on v8.1-a). If you would use C11
> atomics to implement rte_atomic in ARM, you could use a relaxed memory
> order on rte_atomic*_add() (assuming you agree those are the implicit
> semantics of the legacy API) and just get an ldadd instruction. An alternative
The problem is agreeing on the implicit semantics of the legacy APIs. We can find this out in the existing DPDK code. However, given that these APIs are public APIs, they might be used in the applications and we do not know how they are used in the applications.
> would be to implement the same thing in assembler, of course.
>
prev parent reply other threads:[~2020-03-23 17:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 16:42 Honnappa Nagarahalli
2020-03-11 8:25 ` Mattias Rönnblom
2020-03-20 20:45 ` Honnappa Nagarahalli
2020-03-21 8:17 ` Mattias Rönnblom
2020-03-21 8:23 ` Mattias Rönnblom
2020-03-23 17:14 ` Honnappa Nagarahalli
2020-03-23 17:34 ` Mattias Rönnblom
2020-03-24 8:01 ` Morten Brørup
2020-03-24 18:53 ` Honnappa Nagarahalli
2020-03-24 21:41 ` Honnappa Nagarahalli
2020-04-07 5:15 ` Honnappa Nagarahalli
2020-04-09 1:25 ` Chen, Zhaoyan
2020-04-07 19:10 ` Mattias Rönnblom
2020-03-23 17:12 ` Honnappa Nagarahalli [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=VE1PR08MB514926E6CA8EF66A2EE139F198F00@VE1PR08MB5149.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=Gavin.Hu@arm.com \
--cc=Jeff.Brownlee@arm.com \
--cc=Philippe.Robin@arm.com \
--cc=Pravin.Kantak@arm.com \
--cc=Song.Zhu@arm.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=mattias.ronnblom@ericsson.com \
--cc=nd@arm.com \
--cc=thomas@monjalon.net \
/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).