From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) by mail.toke.dk (Postfix) with ESMTPS id 3B5A4A1D3D0 for ; Sun, 30 Jul 2023 15:13:05 +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=JtYe5dOm Received: by mail-qk1-x72d.google.com with SMTP id af79cd13be357-76c97a137c8so43650185a.1 for ; Sun, 30 Jul 2023 06:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690722783; x=1691327583; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=+Xl0Xk/CWkHizqwFzytJhxVEJgtFNDj54nvTxyZ+ajg=; b=JtYe5dOmpe4WUrEJ5tTvGAsPY0wjHs4R7IUwRAy/WZ4j5EwEpmd1VW3oUj/QJ3dfZ2 35KHVcwTEuKeqLiDFWsgN/dKYzjWWLbDYJqO2txtN8SFfZXcliZ9BCPYibY3ZkjX0F95 qzTA+9/Vmxq5uxLZBhOu0vU1Qg9+pacBNebD3lsSeR/eGRBWK/ca0s8+FgM4CvuTBf81 AVtD2rYkqx3iovWVFaG7pzhI42HtgU6UDUELM8T5cVLAMVjYcshsONOSGSttCXE96ZoX o2xGt/BA+NExR99khfKXfUUeGBEtZBymIBickYGn4MsKDqdQ+4ZjDTkUfre3FsMyNuDA TjXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690722783; x=1691327583; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=+Xl0Xk/CWkHizqwFzytJhxVEJgtFNDj54nvTxyZ+ajg=; b=ReB5MtUCO62igwr20UDz4Bw8IwF+XdN7dhyzYj4E5B1uAMVbTVEz7lO9LNMC62jSCp V7O9att5560PXJnBGPmBqmIhjhdUghDmSK/jcFxj92Q++IK5YisB8+trD4uTP4SH/Lls YE4il5BfBMkz/wg1ieTzbBBmkFrMvExkkcHKO1/CIRbcW8pTZIsWeIntKbwuZ1gj3vKe chIQpBK/C7cmkyX7uAS1c9v6/SzMcP9BdABP0LCeWUeshAa1STb2w1N8OHcs8qIXvuye +llwsFQObqh16R54E4ut+ivhWUvlaEmvSoFiT8QOQ1YtcY7cs7n0uYCj43TJww8jclrA XJvQ== X-Gm-Message-State: ABy/qLZFcf0/7HHHm1vhQ5vlMQe6AWEsgxSqiGTudiXeStT72eWnFVDT PUyzJctWdss0GKNgsHQrjc4= X-Google-Smtp-Source: APBJJlH6yFKR+iF//Db+L1j+YN21fGPfsHxHmAng3xAT+4+htwFCe0fASXzXHDmHRH9EWcPt0QPBFg== X-Received: by 2002:a05:620a:46a0:b0:765:734b:1792 with SMTP id bq32-20020a05620a46a000b00765734b1792mr10500470qkb.23.1690722783042; Sun, 30 Jul 2023 06:13:03 -0700 (PDT) Received: from localhost (172.174.245.35.bc.googleusercontent.com. [35.245.174.172]) by smtp.gmail.com with ESMTPSA id 19-20020a05620a071300b007655a4c5423sm855023qkc.130.2023.07.30.06.13.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Jul 2023 06:13:02 -0700 (PDT) Date: Sun, 30 Jul 2023 09:13:02 -0400 From: Willem de Bruijn To: Alexei Starovoitov , Willem de Bruijn Message-ID: <64c661de227c2_11bfb629493@willemb.c.googlers.com.notmuch> In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: QCDSCCEGPAQ5ORKVNUQF5UC3PVWPF3IF X-Message-ID-Hash: QCDSCCEGPAQ5ORKVNUQF5UC3PVWPF3IF 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: 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: 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 wrote: > > > > > > > > +union xdp_csum_info { > > > > + /* Checksum referred to by ``csum_start + csum_offset`` is co= nsidered > > > > + * 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 contain= ers > 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? = > > > > + /* 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 check= sum > > > or XDP_CHECKSUM_UNNECESSARY. > > > > > > > +}; > > > > + > > > > +enum xdp_csum_status { > > > > + /* HW had parsed several transport headers and validated thei= r > > > > + * checksums, same as ``CHECKSUM_UNNECESSARY`` in ``sk_buff``= . > > > > + * 3 least significant bytes contain number of consecutive ch= ecksums, > > > > + * starting with the outermost, reported by hardware as valid= . > > > > + * ``sk_buff`` checksum level (``csum_level``) notation is pr= ovided > > > > + * for driver developers. > > > > + */ > > > > + XDP_CHECKSUM_VALID_LVL0 =3D 1, /* 1 outermost chec= ksum */ > > > > + XDP_CHECKSUM_VALID_LVL1 =3D 2, /* 2 outermost chec= ksums */ > > > > + XDP_CHECKSUM_VALID_LVL2 =3D 3, /* 3 outermost chec= ksums */ > > > > + XDP_CHECKSUM_VALID_LVL3 =3D 4, /* 4 outermost chec= ksums */ > > > > + XDP_CHECKSUM_VALID_NUM_MASK =3D GENMASK(2, 0), > > > > + XDP_CHECKSUM_VALID =3D XDP_CHECKSUM_VALID_NUM_MA= SK, > > > > > > 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, wha= t > > 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. I did not know how much this was used, but quick grep for non constant csum_level shows devices from at least six vendors.