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

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

[Honnappa Nagarahalli]

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.

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

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

[Ananyev, Konstantin]

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

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

[Honnappa Nagarahalli]

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