From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by mail.toke.dk (Postfix) with ESMTPS id DDB85A1D826 for ; Mon, 31 Jul 2023 18:43:27 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=fMHJ+meO Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 573A56122B; Mon, 31 Jul 2023 16:43:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7515FC433C7; Mon, 31 Jul 2023 16:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690821804; bh=ZFs/BvicYu7gy4mLmfp20c2N/r8/MPwILXQgAwW+MKI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fMHJ+meOYIn4z+hIkvHykH/WKCpJD69jhaMx0WAV5oDypdLxra9UEvoCC1GyQF9wb EJsQQqkUB+R+HujYW5LMTO9GoXGfXoh4fNPKw4PoCfO37v+BrpSDbT4M/DmzTP+nkb Zkp28fej6+ucZWzMVIw6QJS8JF/YCic7sQo1HXN5yX3qiLThsYTTuFXXOUvqXHRwjf QA+o4r7sIvG+14miuO9/yJnok2kIutdIxw+9iP1bYsMgapeezKz+G31ucorkAiqROX t+7UCP4YbYVcWsK1T25ZzlZzAlGGILEHJzTtWd2ukKsysLXekk9ifeYBvoQR+scBsw uyVouN5Tz9HkQ== Date: Mon, 31 Jul 2023 09:43:22 -0700 From: Jakub Kicinski To: Willem de Bruijn Message-ID: <20230731094322.0edd5c6b@kernel.org> In-Reply-To: <64c661de227c2_11bfb629493@willemb.c.googlers.com.notmuch> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: VQYNSOB2E6IAAZOJVAXYASY5WXGDEESX X-Message-ID-Hash: VQYNSOB2E6IAAZOJVAXYASY5WXGDEESX X-MailFrom: kuba@kernel.org 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 , 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 , 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 Sun, 30 Jul 2023 09:13:02 -0400 Willem de Bruijn wrote: > > > 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. > > I did not know how much this was used, but quick grep for non constant > csum_level shows devices from at least six vendors. I thought it was a legacy thing from early VxLAN days. We used to leave outer UDP csum as 0 before LCO, and therefore couldn't convert outer to COMPLETE, so inner could not be offloaded/validated. Should not be all that relevant today.