From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by mail.toke.dk (Postfix) with ESMTPS id 1146CA18F17 for ; Wed, 12 Jul 2023 06:59:58 +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=mm3xhdJq Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-4fb863edcb6so10415409e87.0 for ; Tue, 11 Jul 2023 21:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689137996; x=1691729996; 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=d0nFJ9ERKduwN8ULZvzUXn+MtjUmRnV2HCG69mnBhK8=; b=mm3xhdJqTh1tV30DlTX99oaqpiDinnqIDaXmEjNFnT0h16+C2saMoI4auqNvqm5H12 DuuPdWpniks5XNxdmaFdU9ygUf7ESZtMj7zyyEo3sRsGLbD/m1Jc9CQzOTW62LPhNSdx UlemSHcuEK+LDFwe/1WMxLGFkm786cxsvvBosfV6KCybBrOK3a+xTgsVZ2SscKpG9N19 Zdy27ULxJ4wFHp2RZh/njMTYNbDxSdy9O4gC91EZzRBUjd1n5QBWZGOkuJrw+yuMoBjs gYYAo8hN6fv5OJg7b+5K5mRkGaITXN6aRrH3sdeQuF9e30eOANbh1d+Lo34AQJNJYbMn tYTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689137996; x=1691729996; 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=d0nFJ9ERKduwN8ULZvzUXn+MtjUmRnV2HCG69mnBhK8=; b=Nv2xBVVVzNKSY9z/q94jRsEoTT/16JQzDQoBQPRo3fiOgGWXQCXlFhZpw20RYx/lYP 5pKU7/scncgvQvdR++0ThKip8azJLDlXRgk4YP8S10/l3lFgF6l8doL6yIoDlJe2YxM2 YOqK1c6rwvjNhFSKHd4QKiwzT8Uqw1TryM3CB3haW36cCtbvoSJLRsrhI9q42hFgvqfK uZFc/w76V2koRUtf6cPvj2rTZhy8+2fBhxUvvwMH7JC4Pwd3nrA22kNTFDIYzOyA0g8D HV/OfICUQE+iC2TpkmK5aYtZwxZrdS/2hAxifonVH+qugjlI7lzAeKzAWi4UAh0P0oh7 Rcvw== X-Gm-Message-State: ABy/qLbX1UTxLtORUMUBwefjcYinwGseLKdPQDrYLS8SXb+PQUYT/7iS Mch63OflkP4MqZtNGaFoDEZ2OP0zV+tjwAxOSP0= X-Google-Smtp-Source: APBJJlFaaf77IGocKXUdXiMyBlI3WZuaxFDPMzG9kVlYpgvOg+4oaPKP+qk5uBD26e9FrfNvlKQvdVYstfGq+B6RmzM= X-Received: by 2002:a05:6512:15a3:b0:4fb:89f2:594c with SMTP id bp35-20020a05651215a300b004fb89f2594cmr17084021lfb.56.1689137995800; Tue, 11 Jul 2023 21:59:55 -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: Alexei Starovoitov Date: Tue, 11 Jul 2023 21:59:44 -0700 Message-ID: To: Stanislav Fomichev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: IG54RESSJQPHLUSOLTWFTOV7N5HRGZF7 X-Message-ID-Hash: IG54RESSJQPHLUSOLTWFTOV7N5HRGZF7 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: 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 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 having > the offloads. To clarify: yes, AF_XDP needs generalized HW offloads. I just don't see how xdp tx offloads are moving a needle in that direction. > I hope we can both agree that with an api like > mlx5_l4_csum_offload(bool encap) we can't be 100% certain that the > hw is gonna handle any packet layout? So how is that different > from a generic api that also can't work in all cases? If it's hw specific then yes. Will [mlx5|...]_l4_csum_offload apply to other nics? I doubt. > AF_XDP is a generic layer for low-level access and it provides generic > descriptor format, so why suddenly we have this requirement where we have > to do prog rewrite for every new nic? > > Current AF_XDP programs are pretty portable (obviously depend on > a bunch of nic features), it seems like a good idea to try to preserve > this property? (again, with an asterisk, where we should allow some > differentiation, etc, etc) Agree. AF_XDP needs a generic api that will allow user space request HW to do TSO, csum offload, etc. xdp tx and af_xdp are too different to pull under the same framework. xdp progs will interact with the kernel via kfuncs. af_xdp needs a different api to express packet geometry and offload request= s. The user space cannot do it with bpf programs. In case of AF_XDP the bpf prog in the kernel is a filter only. For the majority of the cases bpf prog is not necessary and shouldn't be required to express HW offloads.