From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by mail.toke.dk (Postfix) with ESMTPS id 790BEA1D12A for ; Sat, 29 Jul 2023 20:04:29 +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=M2lZREb6 Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2b974031aeaso47416641fa.0 for ; Sat, 29 Jul 2023 11:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690653867; x=1691258667; 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=K5zTJ2m7y4gUPHPHwEYR3KU4kKwzaZIM/2cgPL3RDIA=; b=M2lZREb6f3m5/J3yggEV0YpjtZOqHpuL7AvHoDm3iAu9g6ry+ZnHop+roInlkEfEGv 5xUUFHWV141rwPCccFt4EdcNLGXm8zvkOVlps29wRkGZIEV6PASVfJqz76ZPoz5tMifX 9hk9gs7IgpUEMlMayt1yZ0Uu0DPxA1LYojqoyVKr3v1x0GE8qmwg4KodObhvoiIfBVkL agwv+QeG7RkYvxinIwSMEyWExnwRK8LFbEvV7eD8lWi+ZT+lQ/rRd+2618Bhw9bZxn94 1nTkghnOZQ6qyM3WLhUAOn3DYxVNaO2TtShV1Rrndmelkj1ftAZCEIuIcoserIy1WpM1 BPzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690653867; x=1691258667; 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=K5zTJ2m7y4gUPHPHwEYR3KU4kKwzaZIM/2cgPL3RDIA=; b=Z2ZWk1nwquQFcjDOCceNptJkm/s+ScyfvfDDBBmd4VA2ReRl/0dxyDViNVoFKuiBIp 9rJE0kTNbuhfewKChag/tG66L2CnTTvRzVOj3n8R8lFFU1pZPPBlilmbxrxDhZwjB8At HNaBi/7DCviAncmJIq5duFpAwNc7K2g4fk+WYsk9Clrm9D6MQdRid3uo6p0wssvfD1Xm OyIN4QNIL3Lx7+n8NTwf2P8e1Nk2iGCjv2Igym+5FPkG1V8qtvuEsfI4zAFScQds+Zq0 1P7s+DumPxh08FJF22D5B1SwptTsZCLRETRhZQn1VAnTMfms+hCOL4/L813H6jgq1kNJ g/eg== X-Gm-Message-State: ABy/qLYv+4SjQE/WeN+q4GPVTiRv8uTzAMHqgNiqqvkR7gWS7QmvX35g 4xVRm/M4dF2o6Q+HON2bZDzUvuwav7Q4AzfScqc= X-Google-Smtp-Source: APBJJlEm83JwHBYnqV6b7FBIR3SRFxDWJ6rYq6OTRiXSBhRaERzeQ19BCZN38MMYIu5hnlC5x9ZdNpHfci2S1K/69kk= X-Received: by 2002:a2e:978f:0:b0:2b9:b066:66a4 with SMTP id y15-20020a2e978f000000b002b9b06666a4mr3871153lji.4.1690653867374; Sat, 29 Jul 2023 11:04:27 -0700 (PDT) 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> In-Reply-To: <64c53b1b29a66_e235c2942d@willemb.c.googlers.com.notmuch> From: Alexei Starovoitov Date: Sat, 29 Jul 2023 11:04:16 -0700 Message-ID: To: Willem de Bruijn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: WRY7BS7JKWPDGGXUYXQJHJI6FMQFB27L X-Message-ID-Hash: WRY7BS7JKWPDGGXUYXQJHJI6FMQFB27L 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: Larysa Zaremba , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , 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 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 wrote: > > > > > > +union xdp_csum_info { > > > + /* Checksum referred to by ``csum_start + csum_offset`` is consid= ered > > > + * 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 abo= ve. > > 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 containers 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. > > > + /* Checksum, calculated over the whole packet. > > > + * Available, if ``status & XDP_CHECKSUM_COMPLETE``. > > > + */ > > > + u32 checksum; > > > > imo XDP RX should only support XDP_CHECKSUM_COMPLETE with u32 checksum > > or XDP_CHECKSUM_UNNECESSARY. > > > > > +}; > > > + > > > +enum xdp_csum_status { > > > + /* HW had parsed several transport headers and validated their > > > + * checksums, same as ``CHECKSUM_UNNECESSARY`` in ``sk_buff``. > > > + * 3 least significant bytes contain number of consecutive checks= ums, > > > + * starting with the outermost, reported by hardware as valid. > > > + * ``sk_buff`` checksum level (``csum_level``) notation is provid= ed > > > + * for driver developers. > > > + */ > > > + XDP_CHECKSUM_VALID_LVL0 =3D 1, /* 1 outermost checksum= */ > > > + XDP_CHECKSUM_VALID_LVL1 =3D 2, /* 2 outermost checksum= s */ > > > + XDP_CHECKSUM_VALID_LVL2 =3D 3, /* 3 outermost checksum= s */ > > > + XDP_CHECKSUM_VALID_LVL3 =3D 4, /* 4 outermost checksum= s */ > > > + XDP_CHECKSUM_VALID_NUM_MASK =3D GENMASK(2, 0), > > > + XDP_CHECKSUM_VALID =3D XDP_CHECKSUM_VALID_NUM_MASK, > > > > I don't see what bpf prog suppose to do with these levels. > > The driver should pick between 3: > > XDP_CHECKSUM_UNNECESSARY, XDP_CHECKSUM_COMPLETE, XDP_CHECKSUM_NONE. > > > > No levels and no anything partial. please. > > This levels business is an unfortunate side effect of > CHECKSUM_UNNECESSARY. For a packet with multiple checksum fields, what > does the boolean actually mean? With these levels, at least that is > well defined: the first N checksum fields. If I understand this correctly this is intel specific feature that other NICs don't have. skb layer also doesn't have such concept. The driver should say CHECKSUM_UNNECESSARY when it's sure or don't pretend that it checks the checksum and just say NONE.