From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D4A0C11F67 for ; Tue, 29 Jun 2021 18:37:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0501961DE4 for ; Tue, 29 Jun 2021 18:37:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235182AbhF2Sjr (ORCPT ); Tue, 29 Jun 2021 14:39:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:49690 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234971AbhF2Sjn (ORCPT ); Tue, 29 Jun 2021 14:39:43 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 086BE61CC4; Tue, 29 Jun 2021 18:37:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1624991835; bh=nZiC7/KGmj6i/GanMyQvyR9yYYIExYb6CHGyCMPX54I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=h4ttunrbU7BPR9zhqpf3t291Jw5VHnFoulmEvOh06sUFgorZHAbLeYlXwFxwWmArS /RJ1zEHE6/NP0j/2F17uCpLlEg/VDr42onRi1o5ZVsyhcB/M6nFzJsFjdXPpzQwtzJ OCuxi1y4g1xtx6dqxhAXXZfi8mX/p0FMDzS9h8IVqKJpBaK1RzrAv1m4Dr3UFODotl N1qubI7ocBsKTx0EOi8UJG4t+Iulin6YuFPxpf6rVeb0D5Ml/ZjmgJWDbHzgEBronj RdCH0i9ZxkFmTV3uom2QLF7UAx+x1eIzR7cZoEP6Oex9k3Bjz2iS10W2wsVFzzPrCu wuM3kF84IKpcA== Date: Tue, 29 Jun 2021 11:37:14 -0700 From: Jakub Kicinski To: Alexander Duyck Cc: Lorenzo Bianconi , Lorenzo Bianconi , bpf , Netdev , David Miller , Alexei Starovoitov , Daniel Borkmann , shayagr@amazon.com, "Jubran, Samih" , John Fastabend , David Ahern , Jesper Dangaard Brouer , Eelco Chaudron , Jason Wang , Saeed Mahameed , Maciej Fijalkowski , "Karlsson, Magnus" , Tirthendu Subject: Re: [PATCH v9 bpf-next 01/14] net: skbuff: add data_len field to skb_shared_info Message-ID: <20210629113714.6d8e2445@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <8ad0d38259a678fb42245368f974f1a5cf47d68d.1623674025.git.lorenzo@kernel.org> <20210629100852.56d995a6@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Tue, 29 Jun 2021 11:18:38 -0700 Alexander Duyck wrote: > On Tue, Jun 29, 2021 at 10:08 AM Jakub Kicinski wrote: > > > ack, I agree. I will fix it in v10. > > > > Why is XDP mb incompatible with LRO? I thought that was one of the use > > cases (mentioned by Willem IIRC). > > XDP is meant to be a per packet operation with support for TX and > REDIRECT, and LRO isn't routable. So we could put together a large LRO > frame but we wouldn't be able to break it apart again. If we allow > that then we are going to need a ton more exception handling added to > the XDP paths. > > As far as GSO it would require setting many more fields in order to > actually make it offloadable by any hardware. It would require more work, but TSO seems to be explicitly stated as what the series builds towards (in the cover letter). It's fine to make choices we'd need to redo later, I guess, I'm just trying to understand the why. > My preference would be > to make use of gso_segs and gso_size to store the truesize and datalen > of the pages. That way we keep all of the data fields used in the > shared info in the first 8 bytes assuming we don't end up having to > actually use multiple buffers. Is 8B significant? We expect the compiler to load 8B and then slice it out? Can the CPU do that? We're not expecting sinfo to be misaligned (e.g. placed directly after xdp_buff), right?