[v4] doc: announce ring API change
Checks
Commit Message
In order to support the non-blocking ring[1], an API change (additional
argument to rte_ring_get_memsize()) is required in librte_ring. This commit
updates the deprecation notice to pave the way for its inclusion in
19.08.
[1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
v4:
- 19.05 -> 19.08
v3:
- "two changes are planned" -> "one change is planned"
v2:
- Drop the ABI change notice
doc/guides/rel_notes/deprecation.rst | 6 ++++++
1 file changed, 6 insertions(+)
Comments
01/02/2019 15:36, Gage Eads:
> In order to support the non-blocking ring[1], an API change (additional
> argument to rte_ring_get_memsize()) is required in librte_ring. This commit
> updates the deprecation notice to pave the way for its inclusion in
> 19.08.
>
> [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
There is still no agreement on this change?
> 01/02/2019 15:36, Gage Eads:
> > In order to support the non-blocking ring[1], an API change
> > (additional argument to rte_ring_get_memsize()) is required in
> > librte_ring. This commit updates the deprecation notice to pave the
> > way for its inclusion in 19.08.
> >
> > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
> >
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
>
> There is still no agreement on this change?
>
Still none. I was hoping this discussion (http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead to some clear direction, but at this point the effort is stalled.
On Fri, 10 May 2019 14:53:56 +0000
"Eads, Gage" <gage.eads@intel.com> wrote:
> > 01/02/2019 15:36, Gage Eads:
> > > In order to support the non-blocking ring[1], an API change
> > > (additional argument to rte_ring_get_memsize()) is required in
> > > librte_ring. This commit updates the deprecation notice to pave the
> > > way for its inclusion in 19.08.
> > >
> > > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
> > >
> > > Signed-off-by: Gage Eads <gage.eads@intel.com>
> >
> > There is still no agreement on this change?
> >
>
> Still none. I was hoping this discussion (http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead to some clear direction, but at this point the effort is stalled.
The fundamental tradeoff is between non-blocking rings and ABI breakage.
Why not have a new ring type for non-blocking rings since non-blocking
rings are not necessary for all use cases.
On Fri, 2019-05-10 at 07:58 -0700, Stephen Hemminger wrote:
> On Fri, 10 May 2019 14:53:56 +0000
> "Eads, Gage" <gage.eads@intel.com> wrote:
>
> 01/02/2019 15:36, Gage Eads:
> In order to support the non-blocking ring[1], an API change
> (additional argument to rte_ring_get_memsize()) is required in
> librte_ring. This commit updates the deprecation notice to pave the
> way for its inclusion in 19.08.
>
> [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
>
> There is still no agreement on this change?
>
>
> Still none. I was hoping this discussion (
> http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead to some
> clear direction, but at this point the effort is stalled.
>
> The fundamental tradeoff is between non-blocking rings and ABI breakage.
It is also possible to do "non-blocking" (but not lock-free) rings with the
original element size (a pointer per ring slot) as implemented here:
https://github.com/ARM-software/progress64/blob/master/src/p64_ringbuf.c
Some extra (head&tail) metadata is required but I think there is space for that
in the rte_ring structure.
> Why not have a new ring type for non-blocking rings since non-blocking
> rings are not necessary for all use cases.
I proposed a new library ("rte_lfring") with lock-free rings here:
https://mails.dpdk.org/archives/dev/2019-January/124242.html
The lock-free design should be the same as in Gage's patch.
rte_lfring could of course be part of the rte_ring library.
> -----Original Message-----
> From: Ola Liljedahl [mailto:Ola.Liljedahl@arm.com]
> Sent: Friday, May 10, 2019 10:19 AM
> To: stephen@networkplumber.org; Eads, Gage <gage.eads@intel.com>
> Cc: arybchenko@solarflare.com; nd <nd@arm.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; thomas@monjalon.net; Richardson,
> Bruce <bruce.richardson@intel.com>; dev@dpdk.org;
> olivier.matz@6wind.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; Gavin Hu (Arm Technology China)
> <Gavin.Hu@arm.com>
> Subject: Re: [dpdk-dev] [PATCH v4] doc: announce ring API change
>
> On Fri, 2019-05-10 at 07:58 -0700, Stephen Hemminger wrote:
> > On Fri, 10 May 2019 14:53:56 +0000
> > "Eads, Gage" <gage.eads@intel.com> wrote:
> >
> > 01/02/2019 15:36, Gage Eads:
> > In order to support the non-blocking ring[1], an API change
> > (additional argument to rte_ring_get_memsize()) is required in
> > librte_ring. This commit updates the deprecation notice to pave the
> > way for its inclusion in 19.08.
> >
> > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
> >
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
> >
> > There is still no agreement on this change?
> >
> >
> > Still none. I was hoping this discussion (
> > http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead
> > to some clear direction, but at this point the effort is stalled.
> >
> > The fundamental tradeoff is between non-blocking rings and ABI breakage.
>
> It is also possible to do "non-blocking" (but not lock-free) rings with the
> original element size (a pointer per ring slot) as implemented here:
> https://github.com/ARM-
> software/progress64/blob/master/src/p64_ringbuf.c
> Some extra (head&tail) metadata is required but I think there is space for
> that in the rte_ring structure.
>
> > Why not have a new ring type for non-blocking rings since non-blocking
> > rings are not necessary for all use cases.
>
> I proposed a new library ("rte_lfring") with lock-free rings here:
> https://mails.dpdk.org/archives/dev/2019-January/124242.html
> The lock-free design should be the same as in Gage's patch.
>
> rte_lfring could of course be part of the rte_ring library.
>
Just read through the API/ABI stability discussion (https://mails.dpdk.org/archives/dev/2019-April/128969.html). I'll drop my patchset and work on supporting this lfring API instead.
Thanks,
Gage
>
> --
> Ola Liljedahl, Networking System Architect, Arm Phone +46706866373, Skype
> ola.liljedahl
On Fri, May 10, 2019 at 04:28:16PM +0000, Eads, Gage wrote:
> > -----Original Message-----
> > From: Ola Liljedahl [mailto:Ola.Liljedahl@arm.com]
> > Sent: Friday, May 10, 2019 10:19 AM
> > To: stephen@networkplumber.org; Eads, Gage <gage.eads@intel.com>
> > Cc: arybchenko@solarflare.com; nd <nd@arm.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>; thomas@monjalon.net; Richardson,
> > Bruce <bruce.richardson@intel.com>; dev@dpdk.org;
> > olivier.matz@6wind.com; Honnappa Nagarahalli
> > <Honnappa.Nagarahalli@arm.com>; Gavin Hu (Arm Technology China)
> > <Gavin.Hu@arm.com>
> > Subject: Re: [dpdk-dev] [PATCH v4] doc: announce ring API change
> >
> > On Fri, 2019-05-10 at 07:58 -0700, Stephen Hemminger wrote:
> > > On Fri, 10 May 2019 14:53:56 +0000
> > > "Eads, Gage" <gage.eads@intel.com> wrote:
> > >
> > > 01/02/2019 15:36, Gage Eads:
> > > In order to support the non-blocking ring[1], an API change
> > > (additional argument to rte_ring_get_memsize()) is required in
> > > librte_ring. This commit updates the deprecation notice to pave the
> > > way for its inclusion in 19.08.
> > >
> > > [1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
> > >
> > > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > >
> > > There is still no agreement on this change?
> > >
> > >
> > > Still none. I was hoping this discussion (
> > > http://mails.dpdk.org/archives/dev/2019-April/129229.html) would lead
> > > to some clear direction, but at this point the effort is stalled.
> > >
> > > The fundamental tradeoff is between non-blocking rings and ABI breakage.
> >
> > It is also possible to do "non-blocking" (but not lock-free) rings with the
> > original element size (a pointer per ring slot) as implemented here:
> > https://github.com/ARM-
> > software/progress64/blob/master/src/p64_ringbuf.c
> > Some extra (head&tail) metadata is required but I think there is space for
> > that in the rte_ring structure.
> >
> > > Why not have a new ring type for non-blocking rings since non-blocking
> > > rings are not necessary for all use cases.
> >
> > I proposed a new library ("rte_lfring") with lock-free rings here:
> > https://mails.dpdk.org/archives/dev/2019-January/124242.html
> > The lock-free design should be the same as in Gage's patch.
> >
> > rte_lfring could of course be part of the rte_ring library.
> >
>
> Just read through the API/ABI stability discussion
> (https://mails.dpdk.org/archives/dev/2019-April/128969.html). I'll drop my
> patchset and work on supporting this lfring API instead.
+1
Given the discussions related to ABI stability, it looks better to
implement this in another library.
Olivier
@@ -83,3 +83,9 @@ Deprecation Notices
- The size and layout of ``rte_cryptodev_qp_conf`` and syntax of
``rte_cryptodev_queue_pair_setup`` will change to to allow to use
two different mempools for crypto and device private sessions.
+
+* ring: one change is planned for rte_ring in v19.08:
+
+ - rte_ring_get_memsize() will get a new ``flags`` parameter, so it can
+ calculate the memory required for rings that require more than 8B per entry
+ (such as the upcoming non-blocking ring).