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