From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC80329B8E0 for ; Fri, 9 Jan 2026 07:22:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767943378; cv=none; b=Cxd5LDTk6H8cEGCDnNdR910pjC5LzZdqb2h9P8avuJSE46SGkLN6WViKTzAEvmuQqgDxxnO0/ogOZ8pK5XLCwIgN2vwGFcan1o7vJvJSmTIZdVxPLbwnhMKAaOf2wL0Knu4ld+5xzRMaoDSnU2HhtbAWZC6v37PuSYNrWGeGLhU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767943378; c=relaxed/simple; bh=j1W235feRg0KN6FKcAZabBql8JsWIHtShwbmzD/a/pk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UhSh8cZRIz9qoToUlngZlfzMm1UDlmTwwm9vJp1r574sLR5lP7hOwMUurFdZKk6lLkO8odZ+6qvVa2n+8dnPVm2DmTalIfSIP/AdVMbX6Yp6vdUsVgr9E9OvrGKu0veVe79lzjEhydTVXsoPfqmRw5BuN3ay/nWhEJT8n2bQFJ0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Xnjp1M4p; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=DUh44NdF; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Xnjp1M4p"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="DUh44NdF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767943375; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qCNBeC55dwFkYuH90UgwaJbtMoG2cmT0emKakpEw6rI=; b=Xnjp1M4ptpSW0+jI31tUUSDwZnROf0cNrmyB0wp2GQLzts2jrbvdcyrEYlzJzWZBUr2EGA Ip7dJIVWQ5hERodvsBUJz0xa5xdmdwO2Fxwg6rGzW7F2Y6CuhI45Tl31/CA55q5nIplXfd OfBcmUQ01OzE0l03X+sta1iCVfoFxS0= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-379-2b06xMRbNSiFufuuds1w4g-1; Fri, 09 Jan 2026 02:22:54 -0500 X-MC-Unique: 2b06xMRbNSiFufuuds1w4g-1 X-Mimecast-MFC-AGG-ID: 2b06xMRbNSiFufuuds1w4g_1767943373 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-4325b81081aso2980603f8f.3 for ; Thu, 08 Jan 2026 23:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1767943373; x=1768548173; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=qCNBeC55dwFkYuH90UgwaJbtMoG2cmT0emKakpEw6rI=; b=DUh44NdFlG/BZkYtCDz+AzKqgepyqy6QdAbQEYI8fxEFB7n0vvjsVT5mCeKa/J622+ 1komFT4PP/K8b0zFzmzlhKtidKuKwjsrgqdcYxwiD25deWP4mXFZPc6IwXdKhn8msDaD 7HGVZXca6JQIAaqbB+NRQ/4q1ycUl7OVIjk3cML6A5MZSWeF4F8LTHneNyWCSeOacj7H 1QheMDFeX5L3wVidbJuRQnTfHedBUmW8ZDgpong1LBMmDG4jKHn0baL7+GIRSb4sJB29 0Ml15N+VGrY0z1gQRNHrpTUDGKdCJUfmiv3v93qVboOjUgWye4ea+vp94bXEg1maPfDZ 2jKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767943373; x=1768548173; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qCNBeC55dwFkYuH90UgwaJbtMoG2cmT0emKakpEw6rI=; b=WdOZyq+faDn5nSox/Fc+AGMyFK7RTGnE2OBojfOwQBlGHPaZGcxTGOb+Zr31qldJ6O /53CnJzy4GMno/IEV6MNoqIqDYnrHaONphRmADwRwtN86aXABQ9kybQw+e7HJqXQWkHp YYtxP+P2rFm1BVqeLd/r8iPwMjbMluO6HBIQhh1Yup8w3+fP8Jv0VJYK9WxKJukGpV6I wj6cMT1AS9J2ZTegrzZPjWuhpdTgsw+b3YsIVogZVwiMy10m5HRTEu7YdImTaT6JmM+N CMLJSmeC+4HzB7UzuYEU7IhNYquJTyeJSf3S83zTP2EB/+TanhB8aCR4ywXaPlLhqgjk KzfA== X-Forwarded-Encrypted: i=1; AJvYcCUFjOXwWNyxIN38v6ycJPxXtcHxGHJnTkv1mQV5hQwOrUUXE1k4xw3WP7rWkb3YytOhQBOqMVZXV4ishoM=@vger.kernel.org X-Gm-Message-State: AOJu0YzHjE6Zuz8oct6EhV20enPEBbYYGwpwWnA8gY2StD82mJa+NHRD NmGqxY8oMsWUi1wp9Ow6VByliuabiaoRh/SM5h9e/RBjzw051c4+sQ3Fb3BLMjgNwFtW51XHfGl C2gAPlQljjBmx7/OlnleEcwHOvgNkzqdWAblsepfUxz92PKdvCJTDEyw8m9WA99Jxfw== X-Gm-Gg: AY/fxX4alERf6z/cMAYB2kU0KattFq4hgGHtEhiVTC5n/IcadY6a0eYiaatB0qIwbe3 v0xshFdFZGkfIig9F5IqjZ6pzHiaBd+0icrm+J2LSlD7GQJp/8N8+pj8MkhGyPx7gzg4viXSlW1 JxkSpMe8saXLPGwWakcd8JaQ9Njc8ODoXkiEmS5bmF8BeBLNso+WtxfTXAl02E41L26OJP41iou alFq2UQcYCBAisDEp/eKzh8lMTP5pF3q+ln7JrEqHGq+p3UYq9xxadp30mXkJx5g022URE9LLGT mGUOmzPdCr63PW8NjoK6Z5ZBROEmjPG6MLz3h6IzfHvIIQLDn2UgBY6DGDXK9vndtiKaP8IoogL IFu8hUK+JpXe1CbW3agbyaqE5I1wPMoXxeQ== X-Received: by 2002:a05:6000:4201:b0:430:f40f:61ba with SMTP id ffacd0b85a97d-432c3798349mr11115157f8f.41.1767943372955; Thu, 08 Jan 2026 23:22:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IFHdWMIJxf4esvBI4hULstTggLuOtGp39Tkn3cxYuG9NjEAkGwtcZDffJ90hcLBXgcBNIrf8w== X-Received: by 2002:a05:6000:4201:b0:430:f40f:61ba with SMTP id ffacd0b85a97d-432c3798349mr11114886f8f.41.1767943367815; Thu, 08 Jan 2026 23:22:47 -0800 (PST) Received: from redhat.com (IGLD-80-230-31-118.inter.net.il. [80.230.31.118]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0daa84sm20705982f8f.2.2026.01.08.23.22.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jan 2026 23:22:47 -0800 (PST) Date: Fri, 9 Jan 2026 02:22:44 -0500 From: "Michael S. Tsirkin" To: Simon Schippers 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 Message-ID: <20260109021023-mutt-send-email-mst@kernel.org> References: <20260107210448.37851-1-simon.schippers@tu-dortmund.de> <20260107210448.37851-3-simon.schippers@tu-dortmund.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260107210448.37851-3-simon.schippers@tu-dortmund.de> 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 > Signed-off-by: Tim Gebauer > Signed-off-by: Simon Schippers > --- > 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)? 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