[dpdk-dev] [PATCH v5 2/2] doc: announce deprecation of refcnt atomic member

Ananyev, Konstantin konstantin.ananyev at intel.com
Fri Jul 17 18:06:56 CEST 2020


Hi David,
 
> On Fri, Jul 17, 2020 at 4:32 PM David Marchand
> <david.marchand at redhat.com> wrote:
> >
> > On Fri, Jul 17, 2020 at 6:37 AM Phil Yang <phil.yang at arm.com> wrote:
> > >
> > > refcnt_atomic member in structures rte_mbuf and rte_mbuf_ext_shared_info
> > > will be deprecated in 20.11 release.
> > >
> > > Suggested-by: Honnappa Nagarahalli <honnappa.nagarahalli at arm.com>
> > > Signed-off-by: Phil Yang <phil.yang at arm.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
> > > ---
> > >  doc/guides/rel_notes/deprecation.rst | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > > index a58a179..99c9806 100644
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > @@ -129,6 +129,12 @@ Deprecation Notices
> > >    in "rte_sched.h". These changes are aligned to improvements suggested in the
> > >    RFC https://mails.dpdk.org/archives/dev/2018-November/120035.html.
> > >
> > > +* mbuf: ``refcnt_atomic`` member in structures ``rte_mbuf`` and
> > > +  ``rte_mbuf_ext_shared_info`` is of type ``rte_atomic16_t``. Due to adoption
> > > +  of C11 atomic builtins it will be of type ``uint16_t``. ``refcnt_atomic``
> > > +  will be removed in 20.11. It will be replaced with ``refcnt`` of type
> > > +  ``uint16_t``.
> > > +
> > >  * metrics: The function ``rte_metrics_init`` will have a non-void return
> > >    in order to notify errors instead of calling ``rte_exit``.
> > >
> > > --
> > > 2.7.4
> > >
> >
> > Acked-by: David Marchand <david.marchand at redhat.com>
> 
> Bruce, Konstantin,
> 
> This precedes the first open source release so trying with you guys:
> what is the purpose of the RTE_MBUF_REFCNT_ATOMIC build flag?
> Thanks.
> 

As I remember it was possible to build/run DPDK with non-atomic refcnt,
i.e. each lcore manages/works with its own mempools.
Don't know does anyone yet rely on that feature.
  



More information about the dev mailing list