Re: [dpdk-dev] [dpdk-techboard] rte_atomic deprecation discussion for the tech board meeting

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<snip>
> 
> Hi Honnappa,
> 
> >
> > Adding the dev mailing list. We could not complete the discussion today in
> the tech board.
> >
> > It was agreed that the older compilers without C11 atomic API support
> > (stdatomic.h) need to be supported and wrappers around C11 built- ins can
> be provided. OVS [1] implementation was pointed out.
> >
> > [1] https://github.com/openvswitch/ovs/blob/master/lib/ovs-atomic.h
> >
> > Frankly, I am not very convinced that we need C11 atomic APIs. I still
> > think we can live with C11 built-ins. I could not find any information that
> the C11 built-ins will be deprecated. These are supported by both gcc and
> clang.
> 
> I am ok in general with replacing rte_atomic* with gcc C11 buit-ins (as long as
> it doesn’t introduce perfomance drop on IA off course).
> Though I have a concern about replacing rte_*mb() with
> __atomic_thread_fence.
> In particular rte_smp_mb() with
> __atomic_thread_fence(__ATOMIC_SEQ_CST).
> __atomic_thread_fence(__ATOMIC_SEQ_CST) generates *mfence* instruction,
> while rte_smp_mb on x86 expands into much lighter *lock add*.
> 
> Konstantin
Thanks for your comments.
That leaves us with writing our own wrappers. Will go ahead with writing the minimalist wrappers.

> 
> 
> >
> > Another thing that I do not like about C11 atomic APIs is that it
> > provides APIs like atomic_load, atomic_store, atomic_exchange etc
> > which do not take any memory ordering parameter (there are counter
> > parts which take memory order as a parameter). I think it defeats the
> > purpose and will result in code similar to what we have today that uses
> rte_atomic APIs. From this perspective, I prefer built-ins which always require
> memory order, or may be write our own wrappers (if somebody can tell me
> why we need them) that always take memory order parameter.
> >
> > 1 comment inline below.
> >
> > > -----Original Message-----
> > > From: Ferruh Yigit <ferruh.yigit@intel.com>
> > > Sent: Wednesday, April 8, 2020 4:47 AM
> > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> > > techboard@dpdk.org
> > > Cc: nd <nd@arm.com>; Phil Yang <Phil.Yang@arm.com>
> > > Subject: Re: [dpdk-techboard] rte_atomic deprecation discussion for
> > > the tech board meeting
> > >
> > > On 4/7/2020 6:30 AM, Honnappa Nagarahalli wrote:
> > > > Hello,
> > > > 	I would like to add this topic for the agenda this week. By
> > > > deprecation,
> > > I mean no new libraries or drivers using rte_atomic/rte_smp_*mb
> > > APIs. Few decisions we need to make:
> > > >
> > > > 1) When do we deprecate? Suggest the notice going out in 20.05
> > > > with the aim to deprecate immediately after 20.08 release. I just
> > > > hope there won't be a mad rush to push code into 20.08 😊
> > >
> > > Since they are APIs, I am not sure if we can deprecate them before 20.11.
> > >
> > > What I understand from new process is, please correct me if I am
> > > wrong, they can be deprecated in 20.11, so no new application can
> > > use them, but existing binaries can continue to use them. And we can
> > > remove them completely, if we want, in 21.11.
> > >
> > > I saw in the mail thread to update checkpatch to prevent using these
> > > APIs, not sure about using checkpatch to prevent using APIs, I am
> > > for following official deprecation process for it.
> > I do not think I explained what I want clearly. There is already a lot
> > of code that uses rte_atomic/rte_smp_*mb APIs. Converting that is a
> > large effort. If we allow more code to be added to DPDK using these
> > APIs, that work just increases. I am proposing to stop adding more code to
> DPDK using these APIs soon. This is different from the deprecation process
> (more targeted towards the users of DPDK?) as officially defined.
> >
> > >
> > > >
> > > > 2) Suggestion on the ML is to use stdatomic.h. However, it is
> > > > supported in
> > > GCC 4.9 and Clang 3.6. I do not know what it is in ICC. Intel CI is
> > > using GCC
> > > 4.8.5 and Clang 3.4.2. Can these be upgraded?
> > >
> > > GCC 4.8.5 and Clang 3.4.2 are using in CentOS7 and RHEL7, we may
> > > want to keep supporting them, since they seem still in use.
> > >
> > > >
> > > > 3) Thomas asked for 2 maintainers for C11 code - I have offered to
> > > volunteer, no one else has come forward. Would be good to have more
> > > people. Anyone wants to volunteer?
> > > >
> > > > 4) Need others to chip-in to convert the code, especially on the driver
> front.
> > > >
> > > > Thank you,
> > > > Honnappa
> > > >