From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by mail.toke.dk (Postfix) with ESMTPS id 0DF81A18EB9 for ; Wed, 12 Jul 2023 05:23:27 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=YlaqWcaJ Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2b70bfc8db5so88857161fa.2 for ; Tue, 11 Jul 2023 20:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689132206; x=1691724206; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0n8c7kdSJgsXGg8olaGmLIjQ0eKSOKOykwbBGabc4NY=; b=YlaqWcaJw+vpU1wCRykZEl60CpKhT6jUk/Y1bjW6UCi4ZNva9JVBbtpLsOtETJTj06 ve3peQWLNGlzWyUy4kFIQei7TUUsnfKAMSKmvjIyNIF+rrI9Bf44mSMjTOo5dhaFWmdh eLfonbQzZWTcaOY6GB0OXS3y6u+iOu7/IeIVXr7CMwYG29FpBOgv9joLE8UTVoLWKbNu NqDCs60IOZY07yA1M154WdeYKr1F5A8vaT0Mk2Wf1cE926cy8y0mW6o4h5xGoHsgdYwW ZnGD5y5t6eYbPaucY0rXsWxySsRtQjZNYcff8GrcmowixBaZzMHPEGjLMq4ieGXlbxsc 9EaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689132206; x=1691724206; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0n8c7kdSJgsXGg8olaGmLIjQ0eKSOKOykwbBGabc4NY=; b=OhqRoFJq2j/c2XSDjMEZ6UPR3biK1gZ4bilAw+ZWwILMbR76Jx1l7asXlAWlmEQRKw 7MNzIzszxr6YTZ9I4BUSkQDYxT9AoZFAVKPb0Rgd7ZxVN/cZDJQo1TWiClCq6yUF0m7A TDJOOKn42Z5ZnYXTb+RiFNTrMfGvEfjABC91XoN8JaPHFsgJT8h/x39ZKegjQADSkfTU YdsO2k7KACa1hKYP+gz7ncgyELXybYFaHJmy/EpMJo84JXygBW5fQDMtbF9dULYaA4oQ A/5IEDCUJJ87dNwBOSqarTTQJKM9kESlDre90T0BbISMsLdlSlO9DwGXUoXpGdj7nBN/ vNHA== X-Gm-Message-State: ABy/qLaTJxxArHDEBUQj2i1T2Fe574No78pb3QC147222vTCnbIX8VVp Z4SbsJR95/AbY42hMfO8vKhDPgyASCQU110QWn4= X-Google-Smtp-Source: APBJJlHdYyvBw7581xyqZQNstdJn58MVgvYLnbz0GRCQRxxkhjxYsExBO5QP0aBUzrARQWt7y/DJzzb57X7XyRipsI8= X-Received: by 2002:a2e:9a8e:0:b0:2b6:c61c:745b with SMTP id p14-20020a2e9a8e000000b002b6c61c745bmr14770565lji.3.1689132206202; Tue, 11 Jul 2023 20:23:26 -0700 (PDT) MIME-Version: 1.0 References: <20230707193006.1309662-1-sdf@google.com> <20230707193006.1309662-10-sdf@google.com> <20230711225657.kuvkil776fajonl5@MacBook-Pro-8.local> <20230711173226.7e9cca4a@kernel.org> <20230711200740.236b0142@kernel.org> In-Reply-To: <20230711200740.236b0142@kernel.org> From: Alexei Starovoitov Date: Tue, 11 Jul 2023 20:23:14 -0700 Message-ID: To: Jakub Kicinski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: DMUAT6U2JQNCEHIUVOLZDAW36AB3URN3 X-Message-ID-Hash: DMUAT6U2JQNCEHIUVOLZDAW36AB3URN3 X-MailFrom: alexei.starovoitov@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Stanislav Fomichev , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Willem de Bruijn , David Ahern , "Karlsson, Magnus" , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , "Fijalkowski, Maciej" , Jesper Dangaard Brouer , Network Development , xdp-hints@xdp-project.net X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [RFC bpf-next v3 09/14] net/mlx5e: Implement devtx kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Tue, Jul 11, 2023 at 8:07=E2=80=AFPM Jakub Kicinski wr= ote: > > On Tue, 11 Jul 2023 19:37:23 -0700 Alexei Starovoitov wrote: > > > I hope I'm not misremembering but I think I suggested at the beginnin= g > > > to create a structure describing packet geometry and requested offloa= ds, > > > and for the prog fill that in. > > > > hmm. but that's what skb is for. skb =3D=3D packet geometry =3D=3D > > layout of headers, payload, inner vs outer, csum partial, gso params. > > > > bpf at tc layer supposed to interact with that correctly. > > If the packet is modified skb geometry should be adjusted accordingly. > > Like BPF_F_RECOMPUTE_CSUM flag in bpf_skb_store_bytes(). > > > > > All operating systems I know end up doing that, we'll end up doing > > > that as well. The question is whether we're willing to learn from > > > experience or prefer to go on a wild ride first... > > > > I don't follow. This thread was aimed to add xdp layer knobs. > > To me XDP is a driver level. > > Driver is not a layer of the networking stack, I don't think it's > a useful or meaningful anchor point for the mental model. > > We're talking about a set of functionality, we can look at how that > functionality was exposed in existing code. > > > 'struct xdp_md' along with > > BPF_F_XDP_HAS_FRAGS is the best abstraction we could do generalizing > > dma-buffers (page and multi-page) that drivers operate on. > > I think you're working against your own claim. > xdp frags explicitly reuse struct skb_shared_info. Yes they do and it's an implementation detail. skb_shared_info is convenient for drivers to fill in. xdp prog isn't aware of the exact mechanism. skb_shared_info is not exposed to a program. Not sure what point you're trying to make. > > > Everything else at driver level is too unique to generalize. > > skb layer is already doing its job. > > How can you say that drivers are impossible to generalize and than > that the skb layer "is doing its job" ie. generalizes them? Yeah. 'generalize' is a wrong word to use to describe a feature that should have the same look and feel across drivers. What I meant by 'csum impossible to generalize across drivers' is that there is no HW-only path across them. skb layer is doing it through sw fallback and combination of csum_complete/unnecessary. I'm saying that your proposal of "create a structure describing packet geometry and requested offloads" already exists and it's called skb. I see no point doing this exercise again at XDP layer.