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 7D5EF126F1F for ; Thu, 21 Mar 2024 15:41:41 +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=1711035702; cv=none; b=Dl1+1OgwMM17hhYbcy6EAcJYzzpTk4xwgKTArWmfoZ7NxRFNsaKdD1Rm6YchMKMZ192Syz65SICB6lQL0mzrpXkfaw7K8LqWP/QPfusy9r5DtWOy0tW5SqaCjPXznb7bBbEEOVs3dFF1+o4ZR/VHrAs5a8t92UN1/TWbQ3n13dA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711035702; c=relaxed/simple; bh=411u/QLZGX71Y3U5+YaJNy/+WsA2picHQsAagnJwAyc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TkiXcYheLO8PpRuWN7ZUUDXBJDeRFEZzPCHu/mGduxMQxNlnu73BpGhDiCmU/q4KKsXlUNvLAFIywuZv5DJUJN0CjdqRkRp0m1EZ5DeBqBZvuOPdoN3mQVwKBYG/44E4ChdFS2cXTpzVK3E+7PjoT/YGqd1wZmbYO1ubf/JVcto= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=h7vJaxSc; 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="h7vJaxSc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A514AC433F1; Thu, 21 Mar 2024 15:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711035701; bh=411u/QLZGX71Y3U5+YaJNy/+WsA2picHQsAagnJwAyc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=h7vJaxScSws6Wh/yFpOZN5tf5ImMUNW1YTCi19rQvB4q2ftxMJoKnsUqE7Ebo2TKA l2o/t5P01Pqk1v6K0iZV0Iezk6wnp5jgrPE05h8g1g+YeiwHUmNejfhmDTeSU2ik7M v3vKC3PFQbj4ts0vA33cp+C6uvUBo9Tvrb0lTeSTD/0Jq72covckIhlPkWLzA5lMd2 e+oTsMsGqig8yBjtZIHT01tESblBelKnbtC9bw/RS8KrxexoBvkc7/Wc+iY7+X6f+d Ti1Hddb7tqIyuqQhfWurBb2YqGgw3CgyAJMIM3BV3+/90zPCSZ8zj/FQW6fJcaxyKj 80cIk5Dnhtmcg== Date: Thu, 21 Mar 2024 08:41:39 -0700 From: Jakub Kicinski To: Lynne Cc: Florian Westphal , Netdev , Kuniyu , Willemdebruijn Kernel Subject: Re: Regarding UDP-Lite deprecation and removal Message-ID: <20240321084139.4dac7e74@kernel.org> In-Reply-To: References: 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, 18 Mar 2024 18:58:10 +0100 (CET) Lynne wrote: > Mar 18, 2024, 14:18 by fw@strlen.de: > > Lynne wrote: > > > >> UDP-Lite was scheduled to be removed in 2025 in commit > >> be28c14ac8bbe1ff due to a lack of real-world users, and > >> a long-outstanding security bug being left undiscovered. > >> > >> I would like to open a discussion to perhaps either avoid this, > >> or delay it, conditionally. > >> > > > > Is there any evidence UDP-Lite works in practice? FWIW I also vote to delete UDP-Lite unless we have real uses that show benefit, preferably _in production_. > > I am not aware of any HW that will peek into L3/L4 payload to figure out > > that the 'udplite' payload should be passed up even though it has bad csum. > > > > So, AFAIU L2 FCS/CRC essentially renders entire 'partial csum' premise moot, > > stack will never receive udplite frames that are damaged. Plus FEC protection on top of FCS is increasingly common. I presume someone did mathematical analysis that UDP Lite is sound, but my engineering senses are tingling at the thought that we're simultaneously saying that BER is high enough to want to process damaged packets, and low enough for the internet csum to be sufficiently strong. The whole thing feels a little bit like an attempt to preserve zero-checksum for IPv6. For HW which wants to spit out IP headers followed by a block of raw unchecksummed data. I've done such things in the past on an FPGA out of laziness. Nothing to do with receiving actually damaged frames. > > Did things change? > > > > I do somehow get CRC errors past the Ethernet layer on consumer rtl cards, > by default, with no ethtool changes, so maybe things did change. Yes, but that's just the last hop. Is the entire network going to disable L2 csums? Or are we just going to use the UDP-lite- -abilities on the last hop? > I haven't sacrificed a good cable yet to get a definitive proof. > The cargo-culted way to be sure is to enable rx-all.