Re: [dpdk-dev] Arm roadmap for 20.05

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.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-
> 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.	

>