From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A62DB22A1E1; Sat, 7 Feb 2026 02:57:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770433058; cv=none; b=W8DyLpVrD5fuowcefVfRP/FIk+VPnnqGcPMqO+a6Tpyot06EYpfUDaMyyenX24V6/F4WrvsXnFibFxNzH8cJUckn2dbF3Ashkvy8/JtW5ue4Et6MQyY01xeOsjupx8eh88OaV2k5mjgJ/Rfg7eMelbc1+0JT32msO/bp55a21Ac= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770433058; c=relaxed/simple; bh=fEJXLRawPbdCf3xetPQEnbQsr9d6YyTUk64NobkmyKw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NkvZzwgqOwXQwxeRN+h/WPXcAPq7qiYl8VRzLrcprDMAgxUnZcqh/aCipm82gpPDJSy0GlczRHNVsEJezi2V7H73TvlabycaEkVft4HK01iQy4uvRrI1FPeRYbkFefBHAgx+LIYo3Tth0/cHTOirDonOsAObm81RA42Q64/KBnU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oPkt7rGC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oPkt7rGC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B30CAC116C6; Sat, 7 Feb 2026 02:57:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770433058; bh=fEJXLRawPbdCf3xetPQEnbQsr9d6YyTUk64NobkmyKw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oPkt7rGC0FvsPX3scZHiX4yFkazHdSma2rHcjUNE+XplJnIuJIH+g0x3qT0JrSqP0 e+KSmkhZHKOonSFsWFXjIEHIvSv58IFC1Tpr0o1uCEVxru8ZL6DbGmwhh1uUSSwVXg l8U1urkkBbTwCEEvcsRgFEkis0kn+wl7Yy33vxPtsQcLb9F7BSPCTrfp6f3UWBfEtt LOTYxIx8iHCD75aQc344YfRivo7h5oi2ynwyXCJVlE4WaAkJnbCbTaQy66xB5Yz1SK C+zNBEb/vygekFf+kZ9j2c6PI+3ZP0++LJaOYsxEnBfSIMeqZEviymfulgtLZvpJde JcW6+CxRddl1Q== Date: Fri, 6 Feb 2026 18:57:35 -0800 From: Jakub Kicinski To: Larysa Zaremba Cc: Vladimir Oltean , , "Claudiu Manoil" , Wei Fang , Clark Wang , Andrew Lunn , "David S. Miller" , Eric Dumazet , "Paolo Abeni" , Tony Nguyen , "Przemek Kitszel" , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , "Stanislav Fomichev" , Andrii Nakryiko , "Martin KaFai Lau" , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Simon Horman , Shuah Khan , Alexander Lobakin , "Maciej Fijalkowski" , "Bastien Curutchet (eBPF Foundation)" , Tushar Vyavahare , Jason Xing , "Ricardo B. =?UTF-8?B?TWFybGniiJrCrnJl?=" , Eelco Chaudron , Lorenzo Bianconi , "Toke Hoiland-Jorgensen" , , , , , , Aleksandr Loktionov Subject: Re: [PATCH bpf 6/6] net: enetc: use truesize as XDP RxQ info frag_size Message-ID: <20260206185735.787fb0e5@kernel.org> In-Reply-To: References: <20260203105417.2302672-1-larysa.zaremba@intel.com> <20260203105417.2302672-7-larysa.zaremba@intel.com> <20260205005901.gnju3zmqimtgeu2b@skbuf> <20260204173401.282899d0@kernel.org> <20260205122953.lscemcctayrvszdu@skbuf> <20260205124638.hxzvjiocephzlrk3@skbuf> <20260205134046.pggwyosutj7ggi4i@skbuf> <20260205175408.30ab72a1@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 6 Feb 2026 09:36:21 +0100 Larysa Zaremba wrote: > > FWIW my feeling is that instead of nickel and diming leftover space > > in the frags if someone actually cared about growing mbufs we should > > have the helper allocate a new page from the PP and append it to the > > shinfo. Much simpler, "infinite space", and works regardless of the > > driver. I don't mean that to suggest you implement it, purely to point > > out that I think nobody really uses positive offsets.. So we can as > > well switch more complicated drivers back to xdp_rxq_info_reg(). > > As Vladimir has mentioned, if the driver does not use header split, frags will > have a tailroom of a size of skb_shared_info, so tail growing does work in > practice. > > Allocating a page_pool buffer (given XDP queue has one attached) is certainly an > option, although I am not sure if anyone needs it. Furthermore, growing tail > would still fail for a single-buf case. sbuf is a different code path, sbuf has precise frame_sz per frame, not a single value in rxq, no? Don't mean to argue, just making sure my mental model is correct ;)