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

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

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


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