DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.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>
Subject: Re: [dpdk-dev] Arm roadmap for 20.05
Date: Mon, 23 Mar 2020 17:34:32 +0000	[thread overview]
Message-ID: <a6df56db-b0d3-2e45-c872-1f3eb54b1aad@ericsson.com> (raw)
In-Reply-To: <VE1PR08MB514914B95F2D698D782E595198F00@VE1PR08MB5149.eurprd08.prod.outlook.com>

On 2020-03-23 18:14, Honnappa Nagarahalli wrote:
> <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-
>> 865b
>>>> 3b1e120b-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 would be to implement the same thing
>>> in assembler, of course.
>>>
>>>
>> Another approach might be to just scrap all of the intrinsics and inline
>> assembler used for all the functions in rte_atomic, on all architectures, and
>> use C11 atomics instead.
> Yes, this is the approach we are taking. But, it does not solve the use of rte_atomic APIs in the applications.	

Agreed.


Another question. "C11 atomics" here seems to mean using GCC 
instrinsics, normally used to implement C11 atomics, not C11 atomics 
(i.e. <stdatomic.h>). What is the reason directly calling the 
intrinsics, rather than using the standard API?


With this in mind, wouldn't be better to extend <rte_atomic.h> with 
functions that take a memory ordering parameter? And properly document 
the memory ordering for the functions already in this API, and maybe 
deprecate some functions in favor of others, more C11-like, functions? 
If not, assuming <stdatomic.h> can't be used, wouldn't it be better if 
we added a <rte_stdatomic.h>, which mimics the standard API, maybe with 
some DPDK tweaks, plus potentially with DPDK-specific extensions as well?


Directly accessing instrinsics will lead to things like 
__atomic_add_ifless() (already in DPDK code base), when people need to 
extend the API. This very much look like GCC built-in function, but is not.


Sorry for hijacking the ARM roadmap thread.



  reply	other threads:[~2020-03-23 17:34 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 [this message]
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

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=a6df56db-b0d3-2e45-c872-1f3eb54b1aad@ericsson.com \
    --to=mattias.ronnblom@ericsson.com \
    --cc=Gavin.Hu@arm.com \
    --cc=Honnappa.Nagarahalli@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=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).