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 CD0E3A18E03 for ; Wed, 12 Jul 2023 02:32:29 +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=bJCHI/nE 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 B68EC61625; Wed, 12 Jul 2023 00:32:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65862C433C7; Wed, 12 Jul 2023 00:32:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1689121948; bh=PTOTcpcxaw8WH84nNL7V6AheHGo/Ep2KZo1K6pljj0g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bJCHI/nEmegoQi3lZtuJO8xmipR7Sq5ohXo+8/EEv3dBX4OEtMAjgwM4ZT1xe/hWq XkaFK8qbis4J4tuO+IB0Lri7g0lMuIac+AM7MHH+vYPzbAaov4RF6LhnXbiIr+UWCf mskmKeLInQdXt6e/i0tPpZ5duSE6dNkoQtI9vfCmWV9pfg+L88awR7PhMcOTaEQWZG vQef/tQeC/CldkjcTi2RBEihWBR+5HBHpzd8UVRZCNOj6gEbzWAg3odS3HGXttPkrA 1ZUrsighM82qTD0+7YTZ3GMcxDM1zBPkXrFGuVMShSyWr84wDhGxKhnaC7sKzxC15R jJTrfjj0jSpHg== Date: Tue, 11 Jul 2023 17:32:26 -0700 From: Jakub Kicinski To: Alexei Starovoitov Message-ID: <20230711173226.7e9cca4a@kernel.org> In-Reply-To: <20230711225657.kuvkil776fajonl5@MacBook-Pro-8.local> References: <20230707193006.1309662-1-sdf@google.com> <20230707193006.1309662-10-sdf@google.com> <20230711225657.kuvkil776fajonl5@MacBook-Pro-8.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: NCLAMHTDTYJXSQEB64OJK2N2UMTLMO6F X-Message-ID-Hash: NCLAMHTDTYJXSQEB64OJK2N2UMTLMO6F 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: Stanislav Fomichev , bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org, toke@kernel.org, willemb@google.com, dsahern@kernel.org, magnus.karlsson@intel.com, bjorn@kernel.org, maciej.fijalkowski@intel.com, hawk@kernel.org, netdev@vger.kernel.org, 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, 11 Jul 2023 15:56:57 -0700 Alexei Starovoitov wrote: > I think this proves my point: csum is not generalizable even across veth and mlx5. > Above is a square peg that tries to fit csum_start/offset api (that makes sense from SW pov) > into HW that has different ideas about csum-ing. > > Here is what mlx5 does: > mlx5e_txwqe_build_eseg_csum(struct mlx5e_txqsq *sq, struct sk_buff *skb, > struct mlx5e_accel_tx_state *accel, > struct mlx5_wqe_eth_seg *eseg) > { > if (unlikely(mlx5e_ipsec_txwqe_build_eseg_csum(sq, skb, eseg))) > return; > > if (likely(skb->ip_summed == CHECKSUM_PARTIAL)) { > eseg->cs_flags = MLX5_ETH_WQE_L3_CSUM; > if (skb->encapsulation) { This should be irrelevant today, as LCO exists? > eseg->cs_flags |= MLX5_ETH_WQE_L3_INNER_CSUM | > MLX5_ETH_WQE_L4_INNER_CSUM; > sq->stats->csum_partial_inner++; > } else { > eseg->cs_flags |= MLX5_ETH_WQE_L4_CSUM; > sq->stats->csum_partial++; > } > > How would you generalize that into csum api that will work across NICs ? > > My answer stands: you cannot. > > My proposal again: > add driver specifc kfuncs and hooks for things like csum. > > Kuba, > since you nacked driver specific stuff please suggest a way to unblock this stalemate. I hope I'm not misremembering but I think I suggested at the beginning to create a structure describing packet geometry and requested offloads, and for the prog fill that in. All operating systems I know end up doing that, we'll end up doing that as well. The question is whether we're willing to learn from experience or prefer to go on a wild ride first...