[dpdk-dev] [PATCH v4] doc: announce ring API change
Ola Liljedahl
Ola.Liljedahl at arm.com
Fri May 10 17:19:09 CEST 2019
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 at 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 at 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.
--
Ola Liljedahl, Networking System Architect, Arm
Phone +46706866373, Skype ola.liljedahl
More information about the dev
mailing list