[dpdk-dev] Using C11 atomic semantic

[dpdk-dev] Using C11 atomic semantic

[Thomas Monjalon]

In the techboard of April 22, it has been decided to block patches
using rte_atomicNN_xx and rte_smp_*mb APIs, starting DPDK 20.08.
Meeting minutes:
	http://mails.dpdk.org/archives/dev/2020-April/165143.html
Deprecation notice:
	http://doc.dpdk.org/guides/rel_notes/deprecation.html

Some doc has been submitted to help understanding how to manage atomics:
	http://doc	.dpdk.org/guides/prog_guide/writing_efficient_code.html#locks-and-atomic-operations

Unfortunately the tool to check new code was merged last week:
	http://git.dpdk.org/dpdk/commit/?id=f1602b4a86

As a consequence, I propose to apply the "reject rule" starting DPDK 20.11.

Can we make this rule better advertised with an announce message?
Are the current technical explanations enough?
If not, it would be wonderful to have a blog post explaining the details,
as part of an announce.

Re: [dpdk-dev] Using C11 atomic semantic

[Honnappa Nagarahalli]

+Ruifeng

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, July 20, 2020 10:34 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: ferruh.yigit@intel.com; david.marchand@redhat.com; dev@dpdk.org; Phil
> Yang <Phil.Yang@arm.com>; techboard@dpdk.org
> Subject: Using C11 atomic semantic
> 
> In the techboard of April 22, it has been decided to block patches using
> rte_atomicNN_xx and rte_smp_*mb APIs, starting DPDK 20.08.
> Meeting minutes:
> 	http://mails.dpdk.org/archives/dev/2020-April/165143.html
> Deprecation notice:
> 	http://doc.dpdk.org/guides/rel_notes/deprecation.html
> 
> Some doc has been submitted to help understanding how to manage atomics:
> 	http://doc
> 	.dpdk.org/guides/prog_guide/writing_efficient_code.html#locks-and-
> atomic-operations
> 
> Unfortunately the tool to check new code was merged last week:
> 	http://git.dpdk.org/dpdk/commit/?id=f1602b4a86
> 
> As a consequence, I propose to apply the "reject rule" starting DPDK 20.11.
As far as I know no patch with rte_atomic has gone in 20.08 so far. Are there any patches in RC2/RC3 that need rte_atomic APIs?

> 
> Can we make this rule better advertised with an announce message?
Do you mean an email on dpdk-announce mailing list?

> Are the current technical explanations enough?
The documentation patch you referenced above covers most common cases people will encounter. Even the rte_ring/rte_stack algorithms work on the same principles.

> If not, it would be wonderful to have a blog post explaining the details, as
> part of an announce.
This is in the works. The plan is to send it to you soon and get it out along with the release.

> 

Re: [dpdk-dev] Using C11 atomic semantic

[Thomas Monjalon]

20/07/2020 17:44, Honnappa Nagarahalli:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 
> > In the techboard of April 22, it has been decided to block patches using
> > rte_atomicNN_xx and rte_smp_*mb APIs, starting DPDK 20.08.
> > Meeting minutes:
> > 	http://mails.dpdk.org/archives/dev/2020-April/165143.html
> > Deprecation notice:
> > 	http://doc.dpdk.org/guides/rel_notes/deprecation.html
> > 
> > Some doc has been submitted to help understanding how to manage atomics:
> > 	http://doc	.dpdk.org/guides/prog_guide/writing_efficient_code.html#locks-and-
> > atomic-operations
> > 
> > Unfortunately the tool to check new code was merged last week:
> > 	http://git.dpdk.org/dpdk/commit/?id=f1602b4a86
> > 
> > As a consequence, I propose to apply the "reject rule" starting DPDK 20.11.
> 
> As far as I know no patch with rte_atomic has gone in 20.08 so far. Are there any patches in RC2/RC3 that need rte_atomic APIs?

Yes we have the case of an additional call added in 20.08-rc2
in mlx5 (not yet converted to C11 atomics).

> > Can we make this rule better advertised with an announce message?
> 
> Do you mean an email on dpdk-announce mailing list?

Yes

> > Are the current technical explanations enough?
> 
> The documentation patch you referenced above covers most common cases people will encounter. Even the rte_ring/rte_stack algorithms work on the same principles.
> 
> > If not, it would be wonderful to have a blog post explaining the details, as
> > part of an announce.
> 
> This is in the works. The plan is to send it to you soon and get it out along with the release.

Great

Re: [dpdk-dev] Using C11 atomic semantic

[Honnappa Nagarahalli]

<snip>
> 
> 20/07/2020 17:44, Honnappa Nagarahalli:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > >
> > > In the techboard of April 22, it has been decided to block patches
> > > using rte_atomicNN_xx and rte_smp_*mb APIs, starting DPDK 20.08.
> > > Meeting minutes:
> > > 	http://mails.dpdk.org/archives/dev/2020-April/165143.html
> > > Deprecation notice:
> > > 	http://doc.dpdk.org/guides/rel_notes/deprecation.html
> > >
> > > Some doc has been submitted to help understanding how to manage
> atomics:
> > > 	http://doc
> 	.dpdk.org/guides/prog_guide/writing_efficient_code.html#locks-and-
> > > atomic-operations
> > >
> > > Unfortunately the tool to check new code was merged last week:
> > > 	http://git.dpdk.org/dpdk/commit/?id=f1602b4a86
> > >
> > > As a consequence, I propose to apply the "reject rule" starting DPDK 20.11.
> >
> > As far as I know no patch with rte_atomic has gone in 20.08 so far. Are there
> any patches in RC2/RC3 that need rte_atomic APIs?
> 
> Yes we have the case of an additional call added in 20.08-rc2 in mlx5 (not yet
> converted to C11 atomics).
There is one patch that Phil had put together [1] for mlx5.
Since this is a unconverted module, suggest allowing for 20.08 instead of removing the 'reject rule' patch.

[1] https://patches.dpdk.org/patch/72007/

> 
> > > Can we make this rule better advertised with an announce message?
> >
> > Do you mean an email on dpdk-announce mailing list?
> 
> Yes
> 
> > > Are the current technical explanations enough?
> >
> > The documentation patch you referenced above covers most common cases
> people will encounter. Even the rte_ring/rte_stack algorithms work on the
> same principles.
> >
> > > If not, it would be wonderful to have a blog post explaining the
> > > details, as part of an announce.
> >
> > This is in the works. The plan is to send it to you soon and get it out along
> with the release.
> 
> Great
>