From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 BB028426696 for ; Thu, 4 Jun 2026 11:46:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780573573; cv=none; b=dPAIuBEQiGF6vkBSCGiqdH4FMH/oTLZKLpDVEqeF2lmBSkE+UwLa7jT9l6BlZhNzwQpe7xv28deofRPDWl0QTBZOOEMtjmHrwzqPS6X7wTJjLJdTo5qxztiurio4cDBKRVv8e53Kw3YXO/Tl25YitQ2Lfa+NiEoO+tmTPGhzIWo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780573573; c=relaxed/simple; bh=PWuIcGz5vNTqw02XB6wwcfvjc8RDJqZ8JfYtcJ+Dh/k=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sD6WBoQYjdjS/M/PFy5Hlplf9qA//748P3fItBA1m93UbZIH1PusW52S0QZ/PxtHtcJbesifQ0prD3fLwk4pOloskiZ3HT2JTFdwjFqafBMZqFnADPPE7xpDo1RRsNXpiIEYemctwkqYafrJxdflxy4QZoERHIXQt+24a6ys8cg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jgQgk8oY; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jgQgk8oY" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-45eea68dd6fso325180f8f.2 for ; Thu, 04 Jun 2026 04:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780573570; x=1781178370; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=M39ky5jJ8hrxGUGYRdmHvRvE6Z5mXN7XNJEml5sbr1k=; b=jgQgk8oYL8mNg7fdQg2T0NqICAr5MYWqRzPtjD5XDyhNMT92wFT7a1czpr4TUHja8T Tk5/mc7GkgcE4k08XFCGo//YArjNt9SGFOW+w3bOEv88o9Knjq4F305DrCHXalJ5T9gk oC5aj8ydp2Gvu9FJHic2PKMX/RSmanoTHVDUHAKzvdnRZIza5cgtSGgVwds0y5V8e2ZF Oh0Lnc4gRZL6YfCQgaez8RbcsHTRz3PYzpmko2T6vptvr7/3tJjyBwkk+ehLz/wzdr67 Cwr373mpkiRI/WKYEmFau8BGFMpYaVHZBq+k0SVOUqYIbJ3KM3fD8XqtHicPQ32aARNm xv7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780573570; x=1781178370; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=M39ky5jJ8hrxGUGYRdmHvRvE6Z5mXN7XNJEml5sbr1k=; b=JdgF9dmfJgqiTqGyfiJY1r14Ikz2Ytur1iab1/J87frgpUJpSS4z2n8h46xTmtQMcu EHTKWfn7miwjqqulDF04WNvYeiPPWFB5QWvV9f95sxwpbDnDd1blOmyeBelbqDmr4uEp sjwA3kE6t0D7DWw/8WjeIAzotzAaVxGFlCV96wWeNIjPCMsohEnYgtuQgW6aocqpwqIM K9Tqu9baGNFp76Yh9DSCWXuKwq0ksTS7tv0EIEkLw0UP54iBB4rZVzYLcX32UNNr4cPN Q+2qQXAnMSvVzfFHnKOxq3j8g8TG1gkAPOrteHUDrqmppQaiv7JJ2XWnwStM7iT9Vio6 iKyw== X-Forwarded-Encrypted: i=1; AFNElJ/PIlKR+uVgKpdi/fr4R8zKm/BLF0ECvqH0Oh9FrfhyH8xzYkllWnklcr/36oIwQ6cObNSUTn8=@vger.kernel.org X-Gm-Message-State: AOJu0Yx2chFrbdsGwUjDvBf8DdmUApF/Ney7sO014h+f7lMcBQdWcHa8 OlftXCJrj4038bmJeuE0jEXKtr5fdjdZhf9c4qUBm0w2EI4rUj6k0Fon X-Gm-Gg: Acq92OFLAzSwOIZ8ub1zlXy7HeMyC9WFNzdJHM4NX1e2HX0/lYDBSyhsauQmBcvD8I1 T5nsAQ2HmJLeQhaZVgOs7Ksb+B65ePZylPk4P+L9sxFTTmUTcN3zUnuYg+9ikWg6tVtE86PeZjq 0R0VkuQBbsT5NJDP5v5Jf9JiYFRkGXaHDqcIyV2G8RJbl9/viIs/JsJ6A7ia/3w8gJveYyznJ2Q CjBJ6I7+zDhl6Md/gquy3Jpw55tQwItUPfrfGYImv0oscfAXtMVgEgzThp6D3AUmXTZ0LxOZiGc GhL3eepY8t9OEonexW8yxRWrXyU61nCMylWZkkPTgUEUPLwY0RpOFvvL1HPSLdFCAG8w8gqiXc1 nn5x//2aAoxEU+5JW7yRcnYfNEljMVSDNu4zl170LWKVdqtKO0Abej0Baf2/zhRu7T6d5DdcZoi s1wAlHqLfX939+vGCZmRJJw1AlzJftFMsmrlADTzuA9lORRNCaAlWNdYEqrtWzqaILt157Hbg= X-Received: by 2002:adf:f8c4:0:b0:460:e0f:8d19 with SMTP id ffacd0b85a97d-4602179121cmr9540725f8f.9.1780573569802; Thu, 04 Jun 2026 04:46:09 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f3444fesm17351838f8f.20.2026.06.04.04.46.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2026 04:46:09 -0700 (PDT) Date: Thu, 4 Jun 2026 12:46:06 +0100 From: David Laight To: Justin Lai 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 Message-ID: <20260604124606.7143581b@pumpkin> In-Reply-To: <447c46ad1f654222a8daa423149f0b89@realtek.com> References: <20260601062341.63981-1-justinlai0215@realtek.com> <5c095b26-9720-45b0-a8d5-a8495291e45b@lunn.ch> <447c46ad1f654222a8daa423149f0b89@realtek.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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 Thu, 4 Jun 2026 08:33:51 +0000 Justin Lai wrote: > 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. 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. If the skb is fragmented then you need to move data into the header not pad the frame. If the hardware really is broken then I suspect you need to disable the feature and suffer the consequences. > > > > > > If the transport data is smaller than RTASE_MIN_PAD_LEN, the remaining > > > data is insufficient for further parsing and causes hardware 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.html > > > > 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. Is that a longer length? Excessive frame padding (beyond 60+FCS) can be treated as a protocol error. -- David > > 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 >