From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 746B01C8629; Fri, 26 Sep 2025 11:45:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758887140; cv=none; b=qlWlpYFSddE1frP91y7ufzsc+/W0w6ujIYMB6Z10UNPJFMr0SAZQSiJEs0+DqZk2mSvopu6vHfEphGGKbTfs9FRXbbdBfJKJ3bujQmF9ahZHd18evqs7rIjhZ7cISnQ/SxsLOzCxrRWpmHmIw9VIoYYTOwmdXQqa3CDZfIr9+CI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758887140; c=relaxed/simple; bh=3p/zksHoTQfao3BPvqFX4RMOp4cSxk0GEr/+msJfFRE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=q3SBJX8jflN9hqgCjJ07heMiDRVNNBPHhbZeUACeJMaevXwpsvhSUOV6yTrnO8IbzU0Nfgz0YXGX/7DS9X5HZ1CYwK87a/+kRbKHMQEpi5qcdmcSnh7wD3xlDgvC/NUVT2v45yAFKmOsIYvvo9tjspuJV9FjjO+QnYYB0Mw4XrQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hyWpuq3T; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hyWpuq3T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8DB4C4CEF4; Fri, 26 Sep 2025 11:45:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758887139; bh=3p/zksHoTQfao3BPvqFX4RMOp4cSxk0GEr/+msJfFRE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hyWpuq3TyODWW5FSWDcR6mPPW6c11FJrxyoey2lMUD/yZ0UFSEYHAiFAk/xp7WG9A CeLM0BjMD24Y1L4FfgGtadPYCUvhCKwQ9KHWQio5BYvBEHKEwTwGe6NgFTNL89IQRN i2BjaCst9Au5sGPgjgod/q2qXjZKPHW0cz9Pp+8E4VbUGd81sV+RXRfiS0RB/hjplq FjVmZvvrGNfB6fE74uL3xd2o0RiegodV+9X9znJyYr6ej5YKnENCcRYw3r14kPAvGq 5rFohfxbDzVNLSUo6ehNbbV1OL2e08w+ztgk6whnYtcTO48zZAPeI4Xqnlf6LYM+FU YE/0qZjgKYs2g== Message-ID: Date: Fri, 26 Sep 2025 13:45:29 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC bpf-next v2 0/5] Add the the capability to load HW RX checsum in eBPF programs To: Jakub Sitnicki , Lorenzo Bianconi Cc: Donald Hunter , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Stanislav Fomichev , Andrew Lunn , Tony Nguyen , Przemek Kitszel , Alexander Lobakin , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Shuah Khan , Maciej Fijalkowski , netdev@vger.kernel.org, bpf@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-kselftest@vger.kernel.org, kernel-team References: <20250925-bpf-xdp-meta-rxcksum-v2-0-6b3fe987ce91@kernel.org> <87bjmy508n.fsf@cloudflare.com> <87tt0q3ik9.fsf@cloudflare.com> Content-Language: en-US From: Jesper Dangaard Brouer In-Reply-To: <87tt0q3ik9.fsf@cloudflare.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 25/09/2025 12.58, Jakub Sitnicki wrote: > On Thu, Sep 25, 2025 at 12:39 PM +02, Lorenzo Bianconi wrote: >>> On Thu, Sep 25, 2025 at 11:30 AM +02, Lorenzo Bianconi wrote: >>>> Introduce bpf_xdp_metadata_rx_checksum() kfunc in order to load the HW >>>> RX cheksum results in the eBPF program binded to the NIC. >>>> Implement xmo_rx_checksum callback for veth and ice drivers. >>> >>> What are going to do with HW RX checksum once XDP prog can access it? >> >> I guess there are multiple use-cases for bpf_xdp_metadata_rx_checksum() >> kfunc. The first the I have in mind is when packets are received by an af_xdp >> application. In this case I think we currently do not have any way to check if >> the packet checksum is correct, right? >> I think Jesper has other use-cases in mind, I will let him comment >> here. > > Can you share more details on what the AF_XDP application would that > info? Today the AF_XDP application need to verify the packet checksum, as it gets raw xdp_frame packets directly from hardware (no layer in-between checked this). Getting the RX-checksum validation from hardware info will be very useful for AF_XDP, as it can avoid doing this in software. > Regarding the use cases that Jesper is trying to unlock, as things stand > we don't have a way, or an agreement on how to inject/propagate even the > already existing NIC hints back into the network stack. > This patchset have its own merits and shouldn't be connected with my use-case of (optionally) including hardware offloads in the xdp_frame. Sure, I obviously also want this RX-checksum added, but this patchset is useful on it's own. > Hence my question - why do we want to expose another NIC hint to XDP > that we can't consume in any useful way yet? > Well here *are* useful ways to use this RX-checksum info on its own. See my explanation of the DDoS use-case here[1] in other email. Cloudflare actually also have a concrete use-case for needing this. Our XDP based Unimog[2] load-balancer (and DDoS) encapsulate all packets when they are XDP_TX forwarded. The encap receiving NIC lacking inner-packet checksum validation make us loose this hardware offload. This would allow us to save some checksum validation or even just DDOS drop based on hardware checksum validation prior to encap (as in [1]). --Jesper [1] https://lore.kernel.org/all/0608935c-1c1c-4374-a058-bc78d114c630@kernel.org/ [2] https://blog.cloudflare.com/unimog-cloudflares-edge-load-balancer/