From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rtits2.realtek.com.tw (rtits2.realtek.com [211.75.126.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4657347B42F; Thu, 4 Jun 2026 13:43:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=211.75.126.72 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780580634; cv=none; b=pnqD31EwcQvTeQeymHPQGbwp8W8ieHkwsG0KgkVlpO49R0wPq3eu0N/PGbT1OnpTZ/IK1QKSD+Gfi1oF1c+yp8LezNQ0UUjsEoB9rqmfi8g6JahdgQKB/PoGpp5UQn2fCKynxLQMVfbF5AjuT0IowXRlnY7hGpbzVSZPCSIl/4s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780580634; c=relaxed/simple; bh=hG3r8htHbfiDt+uEHddzqt17QFqacFYRgXcs1OsJfGc=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=nP6dUEps5SnL+V9QrdNgCc2G2qAo3gpl4kfv5H0wh9B3BnX8ZxYVcVEOLLhYy3LdCFz2VNse0U2kOcsQcO1OkLop1qH5B9U1v+5IZHbGJjgBz6TZ9zqWE4K+5UEqi4vbtntRi+D6gMfQsAsBiCXuSwUEQ7AknjBnRisB8yfJfoM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=realtek.com; spf=pass smtp.mailfrom=realtek.com; dkim=pass (2048-bit key) header.d=realtek.com header.i=@realtek.com header.b=T0HENZKj; arc=none smtp.client-ip=211.75.126.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=realtek.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=realtek.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=realtek.com header.i=@realtek.com header.b="T0HENZKj" X-SpamFilter-By: ArmorX SpamTrap 5.80 with qID 654DhQF11402774, This message is accepted by code: ctloc85258 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realtek.com; s=dkim; t=1780580606; bh=EEX3ee8jRD5bwP1IqMXXbg12zVubnYeMQXiZtasPp4Q=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=T0HENZKjZBkZIRf9xO+VTJsKWzOyrwElwz5Z4WgvJt4JK0YZOIgtYcmqZyfW2xFAg 7I0Ke0rlp/HY6ss1YXN//wVoVTVP7kKdqs+7UHThpInnDzImJmIrpy3fWM1ySsf2M0 LqAsw3XKFKJ9jSNRejrGKdnXSdrJzmBsLKJxn3KAE1AWj2xBZUBxeOdAWqlwoMIbZV XCFD8kNrQQAItA1kThqojp2SLsXSwGEyttQHBdCSFnGl9OxpdRSZb3MTvxVfU9E/T5 097uP65smpQalkix1yBwahGcIoLn/6Al8/MgjSdWDEJ4XTJEGFE3W2yr4XSaEbieyb q4frWhRJaJ63g== Received: from mail.realtek.com (rtkexhmbs03.realtek.com.tw[10.21.1.53]) by rtits2.realtek.com.tw (8.15.2/3.28/5.94) with ESMTPS id 654DhQF11402774 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 4 Jun 2026 21:43:26 +0800 Received: from RTKEXHMBS04.realtek.com.tw (10.21.1.54) by RTKEXHMBS03.realtek.com.tw (10.21.1.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 4 Jun 2026 21:43:27 +0800 Received: from RTKEXHMBS04.realtek.com.tw ([::1]) by RTKEXHMBS04.realtek.com.tw ([fe80::552f:8b32:656c:c395%6]) with mapi id 15.02.2562.017; Thu, 4 Jun 2026 21:43:27 +0800 From: Justin Lai To: David Laight CC: Andrew Lunn , "kuba@kernel.org" , "davem@davemloft.net" , "edumazet@google.com" , "pabeni@redhat.com" , "andrew+netdev@lunn.ch" , "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "horms@kernel.org" , Ping-Ke Shih , Larry Chiu Subject: RE: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug Thread-Topic: [PATCH] rtase: Workaround for IP fragmented UDP packet hardware bug Thread-Index: AQHc8Y8ydZ9ThmFs6kuJK5zylfdiXbYpKbAAgATsPhD//7BLAIAApasw Date: Thu, 4 Jun 2026 13:43:27 +0000 Message-ID: <1489704deb9844b08848758af95a448e@realtek.com> References: <20260601062341.63981-1-justinlai0215@realtek.com> <5c095b26-9720-45b0-a8d5-a8495291e45b@lunn.ch> <447c46ad1f654222a8daa423149f0b89@realtek.com> <20260604124606.7143581b@pumpkin> In-Reply-To: <20260604124606.7143581b@pumpkin> Accept-Language: zh-TW, en-US Content-Language: zh-TW Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 David Laight wrote: >=20 > On Thu, 4 Jun 2026 08:33:51 +0000 > Justin Lai wrote: >=20 > > Andrew Lunn wrote: > > > > > > On Mon, Jun 01, 2026 at 02:23:41PM +0800, Justin Lai wrote: > > > > The hardware parser incorrectly interprets 319/320 in a short IP > > > > fragmented UDP packet payload as standard PTP destination ports > > > > and treats the fragment as a PTP packet for further parsing. >=20 > Is that a packet that has been segmented by IP, or one where the skb is > fragmented enough that the data in the header is too short? > I thought that IPv4 required an mtu of 128 bytes (ish) and IPv6 somewhat > larger - so I don't see how that is a problem. >=20 > If the skb is fragmented then you need to move data into the header not p= ad > the frame. >=20 > If the hardware really is broken then I suspect you need to disable the f= eature > and suffer the consequences. >=20 > > > > > > > > If the transport data is smaller than RTASE_MIN_PAD_LEN, the > > > > remaining data is insufficient for further parsing and causes hardw= are TX > hang. > > > > > > Where does RTASE_SHORT_PKT_THRESH come into this? > > > > > > RTASE_MIN_PAD_LEN is 47, so matches all packets which need padding > > > up to > > > 60 bytes, plus FCS. There are not many such packets, so why both > > > this all the complexity and just pad all small packets? Do you have > > > any performance numbers which show the complexity is worth it? > > > > > > > Pad these packets so the transport data reaches RTASE_MIN_PAD_LEN > > > > before transmitting to avoid triggering the hardware issue. > > > > > > > > Signed-off-by: Justin Lai > > > > > > Is this a Fix? Please add a Fixes: tag. And base it on net. > > > > > > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.htm > > > l > > > > > > Andrew > > > > > > --- > > > pw-bot: cr > > > > Hi Andrew, > > > > RTASE_MIN_PAD_LEN is not the Ethernet minimum-frame padding > threshold. > > It is the minimum transport-data length required by the hardware > > parser after the packet is incorrectly detected as a PTP packet. > > > > Therefore, this workaround needs to pad the packets which can trigger > > the hardware issue, rather than just padding packets to the Ethernet > > minimum frame size. >=20 > Is that a longer length? > Excessive frame padding (beyond 60+FCS) can be treated as a protocol erro= r. >=20 > -- David >=20 > > > > I agree that RTASE_SHORT_PKT_THRESH is not necessary here. I will > > remove it in the next revision. > > > > Yes, this is a fix. I will add a Fixes tag and repost it against the > > net tree. > > > > Thanks, > > Justin > > Hi David, =20 This is an IP fragmented packet, not a fragmented skb. =20 The issue occurs on a non-initial IP fragment whose payload contains values matching the PTP event/general destination ports (319/320). The hardware parser incorrectly identifies the fragment as a PTP packet and attempts further parsing. =20 The workaround does not modify the IP or UDP length fields. The original protocol headers still describe the actual packet size. =20 Therefore, the protocol-defined payload size remains unchanged. =20 We have tested this workaround and have not observed issues caused by the additional padding. =20 Thanks, Justin