On Tue, 15 Jan 2019 17:59:34 -0600 Gage Eads <gage.e...@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.e...@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.
