From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) by mail.toke.dk (Postfix) with ESMTPS id 39290A19179 for ; Wed, 12 Jul 2023 18:29:13 +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=T/YdCKa4 Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-4814299c981so224163e0c.0 for ; Wed, 12 Jul 2023 09:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689179352; x=1691771352; 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=SCWIxbKtlOhtInuz1uYnTQB5l4QrkHYBBkblWGqAp6I=; b=T/YdCKa4t5s7idf/xPmv18zSSnVBmjtwNHB+1JA7+UquLP6PW8eEWJSd4ikNoONqCZ 6dq7FS0CzMwochyeA+sbyVOL1mLzRQcGm+hzFLuBHTPa4cYgrX45Sj9hiieojd+XMKDp 7seK0b3TGrrKRfYxHj3504ERITOHwsvBq3SUwIt27RfNRxJ1X8TasplxcXOMMfZG4MSF sPOZpHf0uqWmw/UEdtSyb73HMRjPmrxcZeN/C8Ax3tYiMfMiaNc1f0kZeLMEyMbphy3A rZBXL5TY7pDYxnzPwJFYmvzIpve/Fny7cQJeabQyEj9Klar9Y3otRhjUO1ZeNoi17s2H dNzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689179352; x=1691771352; 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=SCWIxbKtlOhtInuz1uYnTQB5l4QrkHYBBkblWGqAp6I=; b=Fyp/paHLsRBykm1hVeEu73hLJ1w8DEOxtrcfwOgmNAQXrCYlleEp6z39X63KMITUfX Msx/6MV5xeEfo0ELTWKmmUGnid36MTdhGS3w+jaGd100nqp0qvUTjw4scd/P9EXazQ+Q uU/pBY1oSRICWaXcSeDy8ERgosv/CjsOzT9x4v7SaczgkjH4uHK2mUNaLXnbrl7qgLME oGk+onlj0JDRAxJRT/cCkPhb4AtICv/6bgu2VlrhNSw/i4coTli8jd9kQWd9YIZfeAkz FmzjrHnTuXhRkNLO99S5piISWdpSIyYzGP3x4fwPsTh9FyaaFS9Jo483ByoYZgqCgt5L zDzw== X-Gm-Message-State: ABy/qLbf4tViKSos76SieMXM+aiRi8eRLk/bYYhTNLjCRVtVCddrSVXO lYFc18xSMRVVSWitfo8GT+duXHnzOzb9sVlfnfY= X-Google-Smtp-Source: APBJJlHh9tgQIUo78AXSalDVsI5ZWlEnnfddyQTtkdcY0CyVJeUVF6NjDJXp9x40yiafPedt3keoZT1EJJw8q8Khfm8= X-Received: by 2002:a1f:5842:0:b0:476:3544:773 with SMTP id m63-20020a1f5842000000b0047635440773mr9870855vkb.11.1689179351780; Wed, 12 Jul 2023 09:29:11 -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> In-Reply-To: From: Willem de Bruijn Date: Wed, 12 Jul 2023 12:28:34 -0400 Message-ID: To: Stanislav Fomichev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: E6DVGBWN25II4G4DS63CRCVCYA5XH5II X-Message-ID-Hash: E6DVGBWN25II4G4DS63CRCVCYA5XH5II X-MailFrom: willemdebruijn.kernel@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: Alexei Starovoitov , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , Jakub Kicinski , =?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 Wed, Jul 12, 2023 at 11:16=E2=80=AFAM Willem de Bruijn wrote: > > On Wed, Jul 12, 2023 at 1:36=E2=80=AFAM Stanislav Fomichev wrote: > > > > On Tue, Jul 11, 2023 at 9:59=E2=80=AFPM Alexei Starovoitov > > wrote: > > > > > > On Tue, Jul 11, 2023 at 8:29=E2=80=AFPM Stanislav Fomichev wrote: > > > > > > > > > > > > This will slow things down, but not to the point where it's on par > > > > with doing sw checksum. At least in theory. > > > > We can't stay at skb when using AF_XDP. AF_XDP would benefit from h= aving > > > > the offloads. > > > > > > To clarify: yes, AF_XDP needs generalized HW offloads. > > > > Great! To reiterate, I'm mostly interested in af_xdp wrt tx > > timestamps. So if the consensus is not to mix xdp-tx and af_xdp-tx, > > I'm fine with switching to adding some fixed af_xdp descriptor format > > to enable offloads on tx. > > > > > I just don't see how xdp tx offloads are moving a needle in that dire= ction. > > > > Let me try to explain how both might be similar, maybe I wasn't clear > > enough on that. > > For af_xdp tx packet, the userspace puts something in the af_xdp frame > > metadata area (headrom) which then gets executed/interpreted by the > > bpf program at devtx (which calls kfuncs to enable particular > > offloads). > > IOW, instead of defining some fixed layout for the tx offloads, the > > userspace and bpf program have some agreement on the layout (and bpf > > program "applies" the offloads by calling the kfuncs). > > Also (in theory) the same hooks can be used for xdp-tx. > > Does it make sense? But, again, happy to scratch that whole idea if > > we're fine with a fixed layout for af_xdp. > > Checksum offload is an important demonstrator too. > > It is admittedly a non-trivial one. Checksum offload has often been > discussed as a pain point ("protocol ossification"). > > In general, drivers can accept every CHECKSUM_COMPLETE skb that Erm.. CHECKSUM_PARTIAL