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 71B2F28BA9F; Wed, 7 May 2025 19:04:58 +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=1746644698; cv=none; b=gSBqzQ9BS6i2iBgMn6ta6RXCr/79osjVLCFoaiLHtIIBroXOlr+AmXmwv2Sr9AhfzWJuWaDfTLLLbIRGrVhwwbE1BfsApZ0OcLvanK/tHVg9kNrj2SuqA7xRET8SoCYkBjDBhNXA7amPaYJmxrH52Itlmp6T/ykRwSZucbxOcxg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746644698; c=relaxed/simple; bh=CRCiIABz/kFgdTeK7BF7RrV6jJF7IbV0KFOhjFLNr0o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eld+dsa8vz31mjm/uGV8UsUEuJI7MuxokMO7baw4Prxk7gIF/LPDnqBQjnw6wVdqC6Ulvp8/b2tuDOb944sDTVRv9t4Aq7jx0Ne433apCfNBRsfm4Im9u2XFQGBWzwbfdLg5Pcp09XRO+JxEPXdtP4srOMR29N/u4WZwcAv9smY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lhRh0Bgp; 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="lhRh0Bgp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D653FC4CEE2; Wed, 7 May 2025 19:04:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746644698; bh=CRCiIABz/kFgdTeK7BF7RrV6jJF7IbV0KFOhjFLNr0o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lhRh0BgpAtDuVzNTHwJeeIpZV8B/fvJdYcifpSbxeLTlR4qy4A9r+y4pzZ8G8SwIq CSIscRiuqpRioY9xkq9ah4CoAGvtS52bMQn/IrpYa6s5DtvDZvPe/BGr119Socc93Q 6LtsrF4ntJJJpjELtxY8qmqyAUP2mcsha+jHKZ9jLCxshFATtyP9oH1uaI3NbXkd2T T4TOR34KmE6bNQZ6kdLnw1vR5X9dn/jLMYyUyAhtAm/j9yxUdf+b+PD738FEq85M/s aUaS15NG0gL0jr7L671fyi3WPfSu8xB+Y4zsO83HLOjHfDFLXydEO+j5dFM8DnJwGI cE1Z69pdf4/1w== Message-ID: Date: Wed, 7 May 2025 21:04:51 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v3] xdp: Add helpers for head length, headroom, and metadata length To: Jon Kohler , Willem de Bruijn Cc: Zvi Effron , Stanislav Fomichev , Jason Wang , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Simon Horman , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "bpf@vger.kernel.org" , Jacob Keller References: <20250506125242.2685182-1-jon@nutanix.com> <681b603ac8473_1e4406294a6@willemb.c.googlers.com.notmuch> <062e886f-7c83-4d46-97f1-ebbce3ca8212@kernel.org> <681b96abe7ae4_1f6aad294c9@willemb.c.googlers.com.notmuch> Content-Language: en-US From: Jesper Dangaard Brouer In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 07/05/2025 19.47, Jon Kohler wrote: > > >> On May 7, 2025, at 1:21 PM, Willem de Bruijn wrote: >> >> >> Jesper Dangaard Brouer wrote: >>> >>> >>> On 07/05/2025 19.02, Zvi Effron wrote: >>>> On Wed, May 7, 2025 at 9:37 AM Jesper Dangaard Brouer wrote: >>>>> >>>>> >>>>> >>>>> On 07/05/2025 15.29, Willem de Bruijn wrote: >>>>>> Stanislav Fomichev wrote: >>>>>>> On 05/06, Jon Kohler wrote: >>>>>>>> Introduce new XDP helpers: >>>>>>>> - xdp_headlen: Similar to skb_headlen >>>>> >>>>> I really dislike xdp_headlen(). This "headlen" originates from an SKB >>>>> implementation detail, that I don't think we should carry over into XDP >>>>> land. >>>>> We need to come up with something that isn't easily mis-read as the >>>>> header-length. >>>> >>>> ... snip ... >>>> >>>>>>> + * xdp_headlen - Calculate the length of the data in an XDP buffer >>>> >>>> How about xdp_datalen()? >>> >>> Yes, I like xdp_datalen() :-) >> >> This is confusing in that it is the inverse of skb->data_len: >> which is exactly the part of the data not in the skb head. >> >> There is value in consistent naming. I've never confused headlen >> with header len. >> >> But if diverging, at least let's choose something not >> associated with skbs with a different meaning. > > Brainstorming a few options: > - xdp_head_datalen() ? > - xdp_base_datalen() ? > - xdp_base_headlen() ? > - xdp_buff_datalen() ? > - xdp_buff_headlen() ? > - xdp_datalen() ? (ZivE, JesperB) > - xdp_headlen() ? (WillemB, JonK, StanislavF, JacobK, DanielB) > What about keeping it really simple: xdp_buff_len() ? Or even simpler: xdp_len() as the function documentation already describe this doesn't include frags. To Jon, you seems to be on a cleanup spree: For SKBs netstack have this diagram documented [1]. Which also explains the concept of a "head" buffer, which isn't a concept for XDP. I would really like to see a diagram documenting both xdp_buff and xdp_frame data structures via ascii art, like the one for SKBs. (Hint, this is actually defined in the header file include/linux/skbuff.h, but converted to RST/HTML format.) [1] https://docs.kernel.org/networking/skbuff.html --Jesper