[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACGkMEuE-j0mwHUvDg9uocGCG78HAX4oCXVbt-YS7t5G1LTPfQ@mail.gmail.com>
Date: Wed, 3 Sep 2025 11:13:07 +0800
From: Jason Wang <jasowang@...hat.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Simon Schippers <simon.schippers@...dortmund.de>, mst@...hat.com, eperezma@...hat.com,
stephen@...workplumber.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
kvm@...r.kernel.org, Tim Gebauer <tim.gebauer@...dortmund.de>
Subject: Re: [PATCH 1/4] ptr_ring_spare: Helper to check if spare capacity of
size cnt is available
On Wed, Sep 3, 2025 at 5:13 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> Simon Schippers wrote:
> > The implementation is inspired by ptr_ring_empty.
> >
> > Co-developed-by: Tim Gebauer <tim.gebauer@...dortmund.de>
> > Signed-off-by: Tim Gebauer <tim.gebauer@...dortmund.de>
> > Signed-off-by: Simon Schippers <simon.schippers@...dortmund.de>
> > ---
> > include/linux/ptr_ring.h | 71 ++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 71 insertions(+)
> >
> > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
> > index 551329220e4f..6b8cfaecf478 100644
> > --- a/include/linux/ptr_ring.h
> > +++ b/include/linux/ptr_ring.h
> > @@ -243,6 +243,77 @@ static inline bool ptr_ring_empty_bh(struct ptr_ring *r)
> > return ret;
> > }
> >
> > +/*
> > + * Check if a spare capacity of cnt is available without taking any locks.
> > + *
> > + * If cnt==0 or cnt > r->size it acts the same as __ptr_ring_empty.
>
> cnt >= r->size?
>
> > + *
> > + * The same requirements apply as described for __ptr_ring_empty.
> > + */
> > +static inline bool __ptr_ring_spare(struct ptr_ring *r, int cnt)
> > +{
> > + int size = r->size;
> > + int to_check;
> > +
> > + if (unlikely(!size || cnt < 0))
> > + return true;
>
> Does !size ever happen.
Yes, see 982fb490c298 ("ptr_ring: support zero length ring"). The
reason is tun reuse dev->tx_queue_len for ptr_ring size.
> Also no need for preconditions for trivial
> errors that never happen, like passing negative values. Or prefer
> an unsigned type.
+1.
Thanks
Powered by blists - more mailing lists