[dpdk-dev] [PATCH] doc: announce ring ABI and API changes

[Stephen Hemminger]

On Tue, 15 Jan 2019 17:59:34 -0600
Gage Eads <gage.eads at intel.com> wrote:

> In order to support the non-blocking ring[1], one ABI change and one API
> change are required in librte_ring. This commit updates the deprecation
> notice to pave the way for their inclusion in 19.05.
> 
> [1] http://mails.dpdk.org/archives/dev/2019-January/123475.html
> 
> Signed-off-by: Gage Eads <gage.eads at intel.com>
> ---
>  doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index d4aea4b46..d74cff467 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -83,3 +83,14 @@ 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: two changes are planned for rte_ring in v19.05:
> +
> +  - The ring head and tail values are planned to be changed from ``uint32_t``
> +    to ``size_t``. This reduces the likelihood of wrap-around to effectively
> +    zero for 64-bit builds, which is important in avoiding the ABA problem in
> +    the upcoming non-blocking ring implementation. (32-bit builds are
> +    unaffected by this change.)
> +  - 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).


Would it be possible to support new and old ring types, either through naming
tricks and/or new ring flag?  Changing things like ring buffer and mbuf are basically
a flag day for all users.

I admit to having a personal interest in this since the API/ABI churn is this
project causes vendors to stay on older code. And older code does not correctly
support newer networks.