[dpdk-dev] [PATCH v4] mbuf: fix mbuf free performance with non atomic refcnt
Olivier MATZ
olivier.matz at 6wind.com
Fri Dec 8 17:19:42 CET 2017
On Fri, Dec 08, 2017 at 08:04:50PM +0400, Ilya Matveychikov wrote:
> Olivier,
>
> > On Dec 8, 2017, at 7:46 PM, Olivier Matz <olivier.matz at 6wind.com> wrote:
> >
>
> >
> > lib/librte_mbuf/rte_mbuf.h | 23 ++++++++++++++++++-----
> > 1 file changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index ce8a05ddf..dd08cb72b 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -764,6 +764,13 @@ rte_mbuf_refcnt_set(struct rte_mbuf *m, uint16_t new_value)
> > rte_atomic16_set(&m->refcnt_atomic, new_value);
> > }
> >
> > +/* internal */
> > +static inline uint16_t
> > +__rte_mbuf_refcnt_update(struct rte_mbuf *m, int16_t value)
> > +{
> > + return (uint16_t)(rte_atomic16_add_return(&m->refcnt_atomic, value));
>
> What’s the purpose of using direct cast to uint16_t here and in other places?
This is just a code move.
Few years ago, I remember that icc was quite quick to trigger warnings when
doing implicit casts. I don't know it it's still true, but that may be the
reason why this was done like this initially, or not.
I agree we could remove this explicit cast, but I think it should go in
another patch, because there are several of them.
Olivier
More information about the dev
mailing list