From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 E0371345CB7; Fri, 5 Dec 2025 07:58:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764921505; cv=none; b=X5oFb5xvdnj1TqRIfmq+PtTbJYxNFEL7Yk65r7jXVPJ0tQowviKFUAhkUj2VzEXDn7/y4abXLXIRZZLuWXseQ/HQJ8cgqMN6m4694iNQ1WpC0Y7DZYVhYq6p0ZF79s5U4mDWjXus+ysKhQoV475f1l2ubz/CkGyg9+TfC7PJsAg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764921505; c=relaxed/simple; bh=GdSs4IOZtRfzPzISB8KAXBPj9abiDx7Q+sT4nyxgnlU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=t0Bm7/WlmiR1qN52hbmNUGh92cMg8WqJvpXXvcup39NRQLh9DTNIT3dm/iPSKOdpQ+cilah7wgHtTQoPH22dvP9w2p742X5kQVNyO8ghawByAkEupOi2RSnFyEIsG4DJTuXLoHZm+uaP/1dm3a5wHId1CLqr/KZJ2+qvHCSkC8g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=VqR7xi3b; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=UQTDx2A2; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="VqR7xi3b"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="UQTDx2A2" Date: Fri, 5 Dec 2025 08:58:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1764921487; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/iVl92zKa3BsxR82OA+CaLiMB0c3yaThaQXm87jGM70=; b=VqR7xi3bnEZyhYAlLO7xyuUU+/jVU3SxgWxz5Hk81iier/vba0fuJdIdyFvt7oSQC0BSlz 4sDSI2H7vMYDZYOym8t3czEDzPE/wLxGffm1jVax6GUwXmGEoLGLClvp0iKOpGDN556Spg 0NnnwBfOcL5eE2ToKmdSKK7dNFIsbJ9bG+xx6WT97NxjGJEJLe6fILuYMi6eiwp5kUfKHZ nTS2wyo5TUbD7aQGWFVfkEF2XxSsne/Fwf1KCD1N697YTFX/WeYiBDteb657BZmXWn50i/ +i/QFJpAbSezKvQsSY6HnnZ9ul4B3nmdZ/LlQZhILNj+S3V2AjK0XSpX+ch86g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1764921487; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/iVl92zKa3BsxR82OA+CaLiMB0c3yaThaQXm87jGM70=; b=UQTDx2A2zNWnEUQpO1czFg5NKl3RS5ecDJUYU3XMiMzHI9Jxv8Inqh8y17FZFZgZtnpofI a2HmilpdNKLgV5Bw== From: Sebastian Andrzej Siewior To: Jon Kohler Cc: Jesper Dangaard Brouer , Jason Wang , "netdev@vger.kernel.org" , Willem de Bruijn , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Stanislav Fomichev , open list , "open list:XDP (eXpress Data Path):Keyword:(?:b|_)xdp(?:b|_)" , Alexander Lobakin Subject: Re: [PATCH net-next v2 5/9] tun: use bulk NAPI cache allocation in tun_xdp_one Message-ID: <20251205075805.vW4ShQvN@linutronix.de> References: <20251125200041.1565663-1-jon@nutanix.com> <20251125200041.1565663-6-jon@nutanix.com> <20251203084708.FKvfWWxW@linutronix.de> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: On 2025-12-03 15:35:24 [+0000], Jon Kohler wrote: > Thanks, Sebastian - so if I=E2=80=99m reading this correct, it *is* fine = to do > the two following patterns, outside of NAPI: >=20 > local_bh_disable(); > skb =3D napi_build_skb(buf, len); > local_bh_enable(); >=20 > local_bh_disable(); > napi_consume_skb(skb, 1); > local_bh_enable(); >=20 > If so, I wonder if it would be cleaner to have something like > build_skb_bh(buf, len); >=20 > consume_skb_bh(skb, 1); >=20 > Then have those methods handle the local_bh enable/disable, so that > the toggle was a property of a call, not a requirement of the call?=20 Having budget =3D 0 would be for non-NAPI users. So passing the 1 is superfluous. You goal seems to be to re-use napi_alloc_cache. Right? And this is better than skb_pool? There is already napi_alloc_skb() which expects BH to be disabled and netdev_alloc_skb() (and friends) which do disable BH if needed. I don't see an equivalent for non-NAPI users. Haven't checked if any of these could replace your napi_build_skb(). Historically non-NAPI users would be IRQ users and those can't do local_bh_disable(). Therefore there is dev_kfree_skb_irq_reason() for them. You need to delay the free for two reasons. It seems pure software implementations didn't bother so far. It might make sense to do napi_consume_skb() similar to __netdev_alloc_skb() so that also budget=3D0 users fill the pool if this is really a benefit. Sebastian