From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by mail.toke.dk (Postfix) with ESMTPS id BF1E5A1F55C for ; Mon, 7 Aug 2023 19:06:46 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20221208 header.b=uPDjltqL Received: by mail-pg1-x549.google.com with SMTP id 41be03b00d2f7-55c7bb27977so4707138a12.0 for ; Mon, 07 Aug 2023 10:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691428003; x=1692032803; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=xCqBPwcGvk4SNm1HywtZ952fQL+NIVgTalXwXvLxX4g=; b=uPDjltqLhHoJE8CSxsuf7vt2t+Uze7UPvuMnwoyK2QkynAL3x9YdBy2gsiB2NBlySX KF0iLHdKeXtWrlhvsZ4xWvX0QiCDH2qKiOASHo8gmV9HXkX487MJQWC74l8qMFrhDfEa F+XSWTHSLi07Yw4pJmj2GVGN8onxL2Phv5QhrE0Di04XwK3ZuG6C9Wpp8+wCFXLbUuLm 4djmJ1ipg/XZYtsPh7/D0I/+otHuzZ70DVAx/WsZtavKjlKeeqLRB5UfXuSSTQpMawWo O/V1y5GuhSTGtlKAFDhoTzcPOCSEwJgde1Z+5aMtw8SsisX2ZN/FOBNrJl8/hsC+aEoC cMnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691428003; x=1692032803; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=xCqBPwcGvk4SNm1HywtZ952fQL+NIVgTalXwXvLxX4g=; b=RYH/3tj26KuVzl+kxahuQLsVr9QvAYIT/XI06UotHrCi2eFX36PQiBGE2erbEvv6Vw r9Sk+PuVhb8Ofrna6wcMvBqYFIaPjPLUhAWjLhaUYhGpd6dw7hzJipqo7m95ssCGIUya c/DiPvVa+BzvL8jBRyT416oj/ike6m7nY4QVVGS3d4upDOghZc2uk9L1FlaodSAS2kFt nqYdeBqiAeCMeWoJRw0+yV2gGKlbVFnL5H2jNXhYZvuEUtYrwxdPcfcf7D2fzeaOopAh KEJYJdatvxemjHHWrRETUqg+gv0qW+ZsMVOY6qb24B+tJD0QOiymuO/ZCJApATKZeEsK jraA== X-Gm-Message-State: AOJu0Yx81R9yBqAHIApbMAUJkTYrYwORt3eabFPTvqtLstGKN4Hlhy7g 8pZGFG7lDAzP96xBNRr638PiDNA= X-Google-Smtp-Source: AGHT+IF1Ub8nnXN9lzviQxESFtGW3uOj/sIuB471K04fFyWhyNrpqbHOMftxvXz27Zww5FuvYIZ2idY= X-Received: from sdf.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5935]) (user=sdf job=sendgmr) by 2002:a63:b218:0:b0:563:3b08:f869 with SMTP id x24-20020a63b218000000b005633b08f869mr46596pge.2.1691428003007; Mon, 07 Aug 2023 10:06:43 -0700 (PDT) Date: Mon, 7 Aug 2023 10:06:41 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230728173923.1318596-1-larysa.zaremba@intel.com> <20230728173923.1318596-13-larysa.zaremba@intel.com> <20230728215340.pf3qcfxh7g4x7s6a@MacBook-Pro-8.local> <64c53b1b29a66_e235c2942d@willemb.c.googlers.com.notmuch> <64c661de227c2_11bfb629493@willemb.c.googlers.com.notmuch> Message-ID: From: Stanislav Fomichev To: Larysa Zaremba Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: DA7ER4QTZWSMZC7DKBDNWLKC7FMMGKKE X-Message-ID-Hash: DA7ER4QTZWSMZC7DKBDNWLKC7FMMGKKE X-MailFrom: 3oyTRZAMKCV4O9BCKKCHA.8KIT9L-DEJPOT9L-LNKFA8P.JAP@flex--sdf.bounces.google.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 , Jesper Dangaard Brouer , Willem de Bruijn , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Hao Luo , Jiri Olsa , David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, Network Development , Simon Horman X-Mailman-Version: 3.3.8 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v4 12/21] xdp: Add checksum hint List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 08/07, Larysa Zaremba wrote: > On Mon, Jul 31, 2023 at 06:03:26PM -0700, Alexei Starovoitov wrote: > > On Mon, Jul 31, 2023 at 3:56=E2=80=AFAM Larysa Zaremba wrote: > > > > > > On Sun, Jul 30, 2023 at 09:13:02AM -0400, Willem de Bruijn wrote: > > > > Alexei Starovoitov wrote: > > > > > On Sat, Jul 29, 2023 at 9:15=E2=80=AFAM Willem de Bruijn > > > > > wrote: > > > > > > > > > > > > Alexei Starovoitov wrote: > > > > > > > On Fri, Jul 28, 2023 at 07:39:14PM +0200, Larysa Zaremba wrot= e: > > > > > > > > > > > > > > > > +union xdp_csum_info { > > > > > > > > + /* Checksum referred to by ``csum_start + csum_offset``= is considered > > > > > > > > + * valid, but was never calculated, TX device has to do= this, > > > > > > > > + * starting from csum_start packet byte. > > > > > > > > + * Any preceding checksums are also considered valid. > > > > > > > > + * Available, if ``status =3D=3D XDP_CHECKSUM_PARTIAL``= . > > > > > > > > + */ > > > > > > > > + struct { > > > > > > > > + u16 csum_start; > > > > > > > > + u16 csum_offset; > > > > > > > > + }; > > > > > > > > + > > > > > > > > > > > > > > CHECKSUM_PARTIAL makes sense on TX, but this RX. I don't see = in the above. > > > > > > > > > > > > It can be observed on RX when packets are looped. > > > > > > > > > > > > This may be observed even in XDP on veth. > > > > > > > > > > veth and XDP is a broken combination. GSO packets coming out of c= ontainers > > > > > cannot be parsed properly by XDP. > > > > > It was added mainly for testing. Just like "generic XDP". > > > > > bpf progs at skb layer is much better fit for veth. > > > > > > > > Ok. Still, seems forward looking and little cost to define the > > > > constant? > > > > > > > > > > +1 > > > CHECKSUM_PARTIAL is mostly for testing and removing/adding it doesn't= change > > > anything from the perspective of the user that does not use it, so I = think it is > > > worth having. > >=20 > > "little cost to define the constant". > > Not really. A constant in UAPI is a heavy burden. >=20 > Sorry for the delayed response. >=20 > I still do not comprehend the problem fully for this particular case,=20 > considering it shouldn't block any future changes to the API by itself. >=20 > But, I personally have no reason to push hard the veth-supporting changes= =20 > (aside from wanting the tests to look nicer). >=20 > Still, before removing this in v5, I would like to get some additional fe= edback=20 > on this, preferably from Jesper (who, if I remember correctly, takes an i= nterest=20 > in XDP on veth) or Stanislav. >=20 > If instead of union xdp_csum_info we will have just checksum as a second= =20 > argument, there will be no going back for this particular kfunc, so I wan= t to be=20 > sure nobody will ever need such feature. >=20 > [...] I'm interested in veth only from the testing pow, so if we lose csum_partial on veth (and it becomes _none?), I don't see any issue with that.