[dpdk-dev] Arm roadmap for 20.05

Honnappa Nagarahalli Honnappa.Nagarahalli at arm.com
Mon Mar 23 18:12:32 CET 2020


<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.
> 


More information about the dev mailing list