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 7323934D4D8; Mon, 23 Feb 2026 23:18:48 +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=1771888728; cv=none; b=I6QTFIwSzbgE0C8hoSSY+/oW2+1Cx077EQOC9lQLMTDztjnGJNqh3VAzJ8Q7qPnLBFET3+xtLI/tHcnKYKR+Gb39moaQc5vCEsChJlmxyA62sU2Sr7tkgrsHx2ytn6GHiK1CVS9csd4gTCmLQSFQMWVvOMnGvjwezQjYwBQy0Bk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771888728; c=relaxed/simple; bh=CYLrkQbplhVLWpLwYQI2kVgix50aUPHsmv7SwhslwTg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZxrXQRdZZ/Dkz2PYtlz0/7z/SAJHXIC7TdbA9ijhYsxfjKQzWFmOwlSC2Q/DiQ3zkfoFIQO11RlzTXyPzOO1R4g9xkCrADxTk/D+B+axkvef1skBjk3OQ3zKx1VrEhSNfVBwYNfo4lkBCr7r31g4JDAqWiYEHhEIA/qlcPQuLw8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TlZbVIG0; 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="TlZbVIG0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9EC4EC116C6; Mon, 23 Feb 2026 23:18:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771888727; bh=CYLrkQbplhVLWpLwYQI2kVgix50aUPHsmv7SwhslwTg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TlZbVIG0zfxSp01GgD2+JrWlDWhpRYIi9iTBhCrYsyrhBEvafKGrz2Sy10Zr/MQkO X1SL7F61crQZeQWRjiwxV8hbfegSYseFSQVFEm3T0eSv7L1gLYAWcFx88Chz+qnBzR qxzUVv9nXlsD5qoFeVw2MpDIz2ZJBws9y/8zBWThrTv1CUFXmms+yQKrqAfBJe58Rj wzoFidKhPfAGKJtuWuzd3CSqX6uLhqXhwQPvDkLXHlNpf/7Xie1DnA9YPLi/1rPJUG 2Uvl9A1L5WmKRP7FY64FUyfKI4LTjN9DyLsOPBIVeTR5NmcYTzMkfxsK50Z4nHKidf m7ZoZ1PlpHIWg== Date: Mon, 23 Feb 2026 15:18:45 -0800 From: Jakub Kicinski To: Lorenzo Bianconi Cc: Donald Hunter , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , 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 , Jakub Sitnicki , netdev@vger.kernel.org, bpf@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH bpf-next v3 1/5] netlink: specs: Add XDP RX checksum capability to XDP metadata specs Message-ID: <20260223151845.06db43b0@kernel.org> In-Reply-To: References: <20260217-bpf-xdp-meta-rxcksum-v3-0-30024c50ba71@kernel.org> <20260217-bpf-xdp-meta-rxcksum-v3-1-30024c50ba71@kernel.org> <20260218174742.62a4074f@kernel.org> <20260219091344.1d8517f3@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 23 Feb 2026 18:11:54 +0100 Lorenzo Bianconi wrote: > > Off the top of my head drivers prefer reporting UNNECESSARY when they > > have both, and reserve COMPLETE for cases where L4 could not be found > > or is incorrect. Why don't we report both? We're using 3 args, we still > > have 3 to go. We could turn ip_summed into a bitmap and have explicit > > output args for both level and csum complete value? > > Ack, thx for the explanation. Just for sake of understanding, is there > any NIC capable of reporting both csum_value and csum for the same packet > in the DMA descriptor? Or is this change needed to be future-proof? Both nfp and fbnic definitely can. Off the top of my head - mlx5 also can, but I haven't double checked. > > One more thing I'd like us to at least have a plan for at this stage > > is how to deal with COMPLETE + modified packet + XDP_PASS. > > Right now some drivers discard COMPLETE when XDP is attached since > > they can't be sure if XDP modifies the packet. Other drivers don't > > and we end up with bad csum splat. Do we have a recommendation on > > the correct behavior? If not - should we have a kfunc to adjust / > > discard csum complete explicitly? > > At the moment there is no way to store the csum value we got running > bpf_xdp_metadata_rx_checksum() in order to be consumed during > xdp_buff/xdp_frame to skb conversion (this info can just be consumed in the > ebpf program bound to the NIC) but I think the scope here is much narrower than the xdp_buf to xdp_frame to skb conversion. We are just pass information between the program and driver which owns xdp_buff. Very similar to your new xmo. We could either tell the driver to discard the csum complete or even add a helper to "adjust" the the csum value. Similar to the helper we have to adjust the csum in TC / skb context. > I guess the issue you pointed out can be solved in the verifier > during program load time. What do you think? It could, but at the verifier level we'd probably have to be fairly coarse-grained. Any write to the packet data would mean csum complete cannot be trusted, that's not too hard. But also any tail call / fentry? I'm not really up to date on the latest in program chaining in BPF but I think a lot of real-life deployments would use either chaining or fentry. So in practice it may be a lot of complexity for having csum complete always disabled w/ XDP, in practice. Up to you. I'm totally okay to just say** that drivers should never report csum complete with XDP (until appropriate API is built). Perhaps this will force those who care about XDP+csum_complete to tell us what their requirements are? [**] "just say" == document and add driver kselftest that validates it