[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