From: "Michael S. Tsirkin" <mst@redhat.com>
To: Simon Schippers <simon.schippers@tu-dortmund.de>
Cc: willemdebruijn.kernel@gmail.com, jasowang@redhat.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, eperezma@redhat.com,
leiyang@redhat.com, stephen@networkplumber.org, jon@nutanix.com,
tim.gebauer@tu-dortmund.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux.dev
Subject: Re: [PATCH net-next v7 2/9] ptr_ring: add helper to detect newly freed space on consume
Date: Fri, 9 Jan 2026 03:31:59 -0500 [thread overview]
Message-ID: <20260109033028-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <a0d5d875-9a9c-4bfe-8943-c7b28185c083@tu-dortmund.de>
On Fri, Jan 09, 2026 at 08:35:31AM +0100, Simon Schippers wrote:
> On 1/9/26 08:22, Michael S. Tsirkin wrote:
> > On Wed, Jan 07, 2026 at 10:04:41PM +0100, Simon Schippers wrote:
> >> This proposed function checks whether __ptr_ring_zero_tail() was invoked
> >> within the last n calls to __ptr_ring_consume(), which indicates that new
> >> free space was created. Since __ptr_ring_zero_tail() moves the tail to
> >> the head - and no other function modifies either the head or the tail,
> >> aside from the wrap-around case described below - detecting such a
> >> movement is sufficient to detect the invocation of
> >> __ptr_ring_zero_tail().
> >>
> >> The implementation detects this movement by checking whether the tail is
> >> at most n positions behind the head. If this condition holds, the shift
> >> of the tail to its current position must have occurred within the last n
> >> calls to __ptr_ring_consume(), indicating that __ptr_ring_zero_tail() was
> >> invoked and that new free space was created.
> >>
> >> This logic also correctly handles the wrap-around case in which
> >> __ptr_ring_zero_tail() is invoked and the head and the tail are reset
> >> to 0. Since this reset likewise moves the tail to the head, the same
> >> detection logic applies.
> >>
> >> Co-developed-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> >> Signed-off-by: Tim Gebauer <tim.gebauer@tu-dortmund.de>
> >> Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de>
> >> ---
> >> include/linux/ptr_ring.h | 13 +++++++++++++
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
> >> index a5a3fa4916d3..7cdae6d1d400 100644
> >> --- a/include/linux/ptr_ring.h
> >> +++ b/include/linux/ptr_ring.h
> >> @@ -438,6 +438,19 @@ static inline int ptr_ring_consume_batched_bh(struct ptr_ring *r,
> >> return ret;
> >> }
> >>
> >> +/* Returns true if the consume of the last n elements has created space
> >> + * in the ring buffer (i.e., a new element can be produced).
> >> + *
> >> + * Note: Because of batching, a successful call to __ptr_ring_consume() /
> >> + * __ptr_ring_consume_batched() does not guarantee that the next call to
> >> + * __ptr_ring_produce() will succeed.
> >
> >
> > I think the issue is it does not say what is the actual guarantee.
> >
> > Another issue is that the "Note" really should be more prominent,
> > it really is part of explaining what the functions does.
> >
> > Hmm. Maybe we should tell it how many entries have been consumed and
> > get back an indication of how much space this created?
> >
> > fundamentally
> > n - (r->consumer_head - r->consumer_tail)?
>
> No, that is wrong from my POV.
>
> It always creates the same amount of space which is the batch size or
> multiple batch sizes (or something less in the wrap-around case). That is
> of course only if __ptr_ring_zero_tail() was executed at least once,
> else it creates zero space.
exactly, and caller does not know, and now he wants to know so
we add an API for him to find out?
I feel the fact it's a binary (batch or 0) is an implementation
detail better hidden from user.
> >
> >
> > does the below sound good maybe?
> >
> > /* Returns the amound of space (number of new elements that can be
> > * produced) that calls to ptr_ring_consume created.
> > *
> > * Getting n entries from calls to ptr_ring_consume() /
> > * ptr_ring_consume_batched() does *not* guarantee that the next n calls to
> > * ptr_ring_produce() will succeed.
> > *
> > * Use this function after consuming n entries to get a hint about
> > * how much space was actually created.
> >
> >
> >
> >
> >
> >> + */
> >> +static inline bool __ptr_ring_consume_created_space(struct ptr_ring *r,
> >> + int n)
> >> +{
> >> + return r->consumer_head - r->consumer_tail < n;
> >> +}
> >> +
> >> /* Cast to structure type and call a function without discarding from FIFO.
> >> * Function must return a value.
> >> * Callers must take consumer_lock.
> >> --
> >> 2.43.0
> >
next prev parent reply other threads:[~2026-01-09 8:32 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-07 21:04 [PATCH net-next v7 0/9] tun/tap & vhost-net: apply qdisc backpressure on full ptr_ring to reduce TX drops Simon Schippers
2026-01-07 21:04 ` [PATCH net-next v7 1/9] ptr_ring: move free-space check into separate helper Simon Schippers
2026-01-07 21:04 ` [PATCH net-next v7 2/9] ptr_ring: add helper to detect newly freed space on consume Simon Schippers
2026-01-08 3:23 ` Jason Wang
2026-01-08 7:20 ` Simon Schippers
2026-01-09 6:01 ` Jason Wang
2026-01-09 6:47 ` Michael S. Tsirkin
2026-01-09 7:22 ` Michael S. Tsirkin
2026-01-09 7:35 ` Simon Schippers
2026-01-09 8:31 ` Michael S. Tsirkin [this message]
2026-01-09 9:06 ` Simon Schippers
2026-01-12 16:29 ` Simon Schippers
2026-01-07 21:04 ` [PATCH net-next v7 3/9] tun/tap: add ptr_ring consume helper with netdev queue wakeup Simon Schippers
2026-01-08 3:38 ` Jason Wang
2026-01-08 7:40 ` Simon Schippers
2026-01-09 6:02 ` Jason Wang
2026-01-09 9:31 ` Simon Schippers
2026-01-21 9:32 ` Simon Schippers
2026-01-22 5:35 ` Jason Wang
2026-01-23 3:05 ` Jason Wang
2026-01-23 9:54 ` Simon Schippers
2026-01-27 16:47 ` Simon Schippers
2026-01-28 7:03 ` Jason Wang
2026-01-28 7:53 ` Simon Schippers
2026-01-29 1:14 ` Jason Wang
2026-01-29 9:24 ` Simon Schippers
2026-01-30 1:51 ` Jason Wang
2026-02-01 20:19 ` Simon Schippers
2026-02-03 3:48 ` Jason Wang
2026-02-04 15:43 ` Simon Schippers
2026-02-05 3:59 ` Jason Wang
2026-02-05 22:28 ` Simon Schippers
2026-02-06 3:21 ` Jason Wang
2026-02-08 18:18 ` Simon Schippers
2026-02-12 0:12 ` Simon Schippers
2026-02-12 7:06 ` Michael S. Tsirkin
2026-02-12 8:03 ` Simon Schippers
2026-02-12 8:14 ` Jason Wang
2026-02-14 17:13 ` Simon Schippers
2026-02-14 18:18 ` Michael S. Tsirkin
2026-02-14 19:51 ` Simon Schippers
2026-02-14 23:49 ` Michael S. Tsirkin
2026-02-15 10:38 ` Michael S. Tsirkin
2026-02-16 13:27 ` Simon Schippers
2026-01-07 21:04 ` [PATCH net-next v7 4/9] tun/tap: add batched ptr_ring consume functions " Simon Schippers
2026-01-07 21:04 ` [PATCH net-next v7 5/9] tun/tap: add unconsume function for returning entries to ptr_ring Simon Schippers
2026-01-08 3:40 ` Jason Wang
2026-01-07 21:04 ` [PATCH net-next v7 6/9] tun/tap: add helper functions to check file type Simon Schippers
2026-01-07 21:04 ` [PATCH net-next v7 7/9] vhost-net: vhost-net: replace rx_ring with tun/tap ring wrappers Simon Schippers
2026-01-08 4:38 ` Jason Wang
2026-01-08 7:47 ` Simon Schippers
2026-01-09 6:04 ` Jason Wang
2026-01-09 9:57 ` Simon Schippers
2026-01-12 2:54 ` Jason Wang
2026-01-12 4:42 ` Michael S. Tsirkin
2026-01-07 21:04 ` [PATCH net-next v7 8/9] tun/tap: drop get ring exports Simon Schippers
2026-01-07 21:04 ` [PATCH net-next v7 9/9] tun/tap & vhost-net: avoid ptr_ring tail-drop when qdisc is present Simon Schippers
2026-01-08 4:37 ` Jason Wang
2026-01-08 8:01 ` Simon Schippers
2026-01-09 6:09 ` Jason Wang
2026-01-09 10:14 ` Simon Schippers
2026-01-12 2:22 ` Jason Wang
2026-01-12 11:08 ` Simon Schippers
2026-01-12 11:18 ` Michael S. Tsirkin
2026-01-13 6:26 ` Jason Wang
2026-01-12 4:33 ` Michael S. Tsirkin
2026-01-12 11:17 ` Simon Schippers
2026-01-12 11:19 ` Michael S. Tsirkin
2026-01-12 11:28 ` Simon Schippers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260109033028-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=jon@nutanix.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=leiyang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=simon.schippers@tu-dortmund.de \
--cc=stephen@networkplumber.org \
--cc=tim.gebauer@tu-dortmund.de \
--cc=virtualization@lists.linux.dev \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox