<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.yi...@intel.com> > > > Sent: Wednesday, April 8, 2020 4:47 AM > > > To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; > > > techbo...@dpdk.org > > > Cc: nd <n...@arm.com>; Phil Yang <phil.y...@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 > > > >
