From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) (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 9A0E634A771 for ; Tue, 23 Dec 2025 19:01:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766516476; cv=none; b=PVi7qEocxn7cnr2S4Nx+meM8l9JCMTJLmnFW0DGwdrgTxhYlUsawCo4ksV2ek2ZZmAQOFKDg3e2knXig/+ysWiGsE5orb4QrCquXvKgiipGEpuLCF2ixDUJTuhF3SFMxB+kkAiCz++rl9nV12K4X7JMk6injWKOzDOgYwJZFvMI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766516476; c=relaxed/simple; bh=5sPCUucu+LKNC3DxCKK37kr4+kpDzrPROK9bTcUINDA=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=M3PGAr4WopbUdsCM+iFKT0TWIwQ1DKIyYbK74mN9yjjdWPSMRpSPDCGpxjaP4wLuY3rRcRAROEtB6jDWvIRE0WVM9atOcMK0cOj4RWUcGgvcd3vjqfc+LOv/YFtlSjo5i/QMq/IxLzalBo4S/Dxr/Ci4b8ctOZ7Pw+9Z4sYe8g0= 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=MzVZCrYO; arc=none smtp.client-ip=209.85.128.182 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="MzVZCrYO" Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-78fc520433aso25653847b3.1 for ; Tue, 23 Dec 2025 11:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766516473; x=1767121273; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=vx0jOvF6tZS8pxKHJ8Mkyoco4/zguV4NZ9A2mS3WuCM=; b=MzVZCrYOtMZX0D0OjU7VlqEAYorMO9fA3iRsQ4wfRytCj5xy3CbQZSsOgg3RiNPKg2 bdgogNw7bFIBUHrLVYOMNnDCNe5RgtHgCP9YIhYY8DCs2Bp2k7Xl9oaNGq3XM7P77jYu ozmXoWQ5WaRZUh2N5ITw2QcrhTCGo5qKNSEFIdJpi4tgk6thC2K1HncjjJXs42r+yWFa gncgVC3n0ahN5iRhwMeZYcoEbMZr8UwDOVjSE2f0FnNu0j1H6MiMaZuMBeUaMskFSuYr tOEz1UaQROFjp0WowFfeYO2Bjkje6MGgSgzfumRdmzpaO7SSx9GQdysK1BPBp6vWp5zV niQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766516473; x=1767121273; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vx0jOvF6tZS8pxKHJ8Mkyoco4/zguV4NZ9A2mS3WuCM=; b=FtVYeAQdPB4zJTkx+ge+nYTDS4APg+NJIektkfaszNJS21Djxrz555QVx2yxrynw20 F35XiTZC4HwxTqBF8gZTW/nmtcsQ4jQ9Og+Xc3K4kez0/zY3m6xT9ocrq8VgpHytKGsI irKTGzBOI8iUaxxXcrp0D53u5/n7RF3TRYJgAyiEX4TzL1DnX5DvKXXak+ehVPzoGH74 YTF7zCo5Cpn531078fBWpO7Kw1QLwz5tbMl71zxxJU+QFYatBlaz/CNlkqvOyDWgUbIr Jx5j/1g5XAMyJhOR3TRl+X5Tlo+gqQswGIpaeYTH6SDlsxZvj6zAuQjjR0L6Aqztq9iH 1e4w== X-Forwarded-Encrypted: i=1; AJvYcCXMeHffC4wSbonvuq0ynCO015FD/4K/Jg+ozQph2jOD7RfNZ+8/MNjFloPiOChriWNKyPpbs9EnZmObM1A=@vger.kernel.org X-Gm-Message-State: AOJu0YwBGssppOUHF3/tVu7mhnuomC0IAv/Q2GIvN5YWDmwjr1UMa4Pf VfPEsyyKAlqkEVco3uG7gct3XQUQIeKBJtDBE3xk4x7tVs/yuJwERy1t X-Gm-Gg: AY/fxX7VWzTsrDUl5W2FkJ9uu+9PV4RWnhc23Qo4DgjSGwMaNhAvu/0f+8T1GLHyZ6f drpeqESn237tFL2sfcUqo+kFWNYJon5JdUjaKMOWwIb0Y07jE3h+/d4/twrbtldCNBPjHF0N7te F98XrRJcsaj72UBVo6LOeYi/YXTVE0ktVekWckV8vFSQmcFkS0lJNrMtLcESjAhwoe4TfWVUabM FFjl3UoRBk+XaTYl5SHO8+v06dqUl/M054hOB6Rw5BqQBg6DGo6QrxkD1mSHdmuXlLdUyNEIRMY /ea+yYXq8QAFLTgZKOuFwptCLsgtJJ2apAbjGDHB3lYlYSQrU9h0SF2Qd56qhYdJAdAnALvY/SV FPZmaeMyshPAT62Glt4TJccfROqgxKvB3ccf1Lul6OIhsqOGGS3zTBSpck3fdv7lAQKiS1uJvR0 cBiejEB5nHyyngQYYuBwFB2PYXPAbf8uQh3VpaOVeOC4Frn4QqDFv0qM1rTQtkDt2ygYLtX6h1I nb+5w== X-Google-Smtp-Source: AGHT+IEWRFlbhvq7/GCqpt+unPpPjWVNkObSkmzQVDUvyG3eowHw3ouJONLooJzvYG8sKv1QFMJ/Wg== X-Received: by 2002:a05:690c:6a04:b0:78c:3007:dabf with SMTP id 00721157ae682-78fb3f2c893mr127569747b3.27.1766516473358; Tue, 23 Dec 2025 11:01:13 -0800 (PST) Received: from gmail.com (141.139.145.34.bc.googleusercontent.com. [34.145.139.141]) by smtp.gmail.com with UTF8SMTPSA id 00721157ae682-78fb437380esm57704487b3.4.2025.12.23.11.01.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Dec 2025 11:01:12 -0800 (PST) Date: Tue, 23 Dec 2025 14:01:11 -0500 From: Willem de Bruijn To: Paolo Abeni , Jibin Zhang , Eric Dumazet , Neal Cardwell , Kuniyuki Iwashima , "David S . Miller" , David Ahern , Jakub Kicinski , Simon Horman , Matthias Brugger , AngeloGioacchino Del Regno , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, steffen.klassert@secunet.com Cc: wsd_upstream@mediatek.com, shiming.cheng@mediatek.com, defa.li@mediatek.com Message-ID: In-Reply-To: References: <20251217035548.8104-1-jibin.zhang@mediatek.com> Subject: Re: [PATCH] net: fix segmentation of forwarding fraglist GRO Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Paolo Abeni wrote: > On 12/17/25 4:55 AM, Jibin Zhang wrote: > > This patch enhances GSO segment checks by verifying the presence > > of frag_list and protocol consistency, addressing low throughput > > issues on IPv4 servers when used as hotspots > > > > Specifically, it fixes a bug in GSO segmentation when forwarding > > GRO packets with frag_list. The function skb_segment_list cannot > > correctly process GRO skbs converted by XLAT, because XLAT only > > converts the header of the head skb. As a result, skbs in the > > frag_list may remain unconverted, leading to protocol > > inconsistencies and reduced throughput. > > > > To resolve this, the patch uses skb_segment to handle forwarded > > packets converted by XLAT, ensuring that all fragments are > > properly converted and segmented. > > > > Signed-off-by: Jibin Zhang > > This looks like a fix, it should target the 'net' tree and include a > suitable Fixes tag. > > > --- > > net/ipv4/tcp_offload.c | 3 ++- > > net/ipv4/udp_offload.c | 3 ++- > > 2 files changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c > > index fdda18b1abda..162a384a15bb 100644 > > --- a/net/ipv4/tcp_offload.c > > +++ b/net/ipv4/tcp_offload.c > > @@ -104,7 +104,8 @@ static struct sk_buff *tcp4_gso_segment(struct sk_buff *skb, > > if (!pskb_may_pull(skb, sizeof(struct tcphdr))) > > return ERR_PTR(-EINVAL); > > > > - if (skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST) { > > + if ((skb_shinfo(skb)->gso_type & SKB_GSO_FRAGLIST) && skb_has_frag_list(skb) && > > + (skb->protocol == skb_shinfo(skb)->frag_list->protocol)) { > > struct tcphdr *th = tcp_hdr(skb); Using fraglist gso on a system that modifies packet headers is a known bad idea. I guess this was not anticipated when the feature was added. But we've seen plenty of examples with BPF already before. This skb->protocol change is only one of a variety of ways that the headers may end up mismatching. It's not bad to bandaid it and fall back onto regular GSO. But it seems like we'll continue to have to play whack-a-mole unless we find a more fundamental solution. E.g., disabling fraglist GRO when such a path is detected, or downgrade an skb to non-fraglist in paths like this XLAT. > > > > if (skb_pagelen(skb) - th->doff * 4 == skb_shinfo(skb)->gso_size) > > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c > > index 19d0b5b09ffa..704fb32d10d7 100644 > > --- a/net/ipv4/udp_offload.c > > +++ b/net/ipv4/udp_offload.c > > @@ -512,7 +512,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb, > > return NULL; > > } > > > > - if (skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST) { > > + if ((skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST) && skb_has_frag_list(gso_skb) && > > + (gso_skb->protocol == skb_shinfo(gso_skb)->frag_list->protocol)) { > > /* Detect modified geometry and pass those to skb_segment. */ > > if (skb_pagelen(gso_skb) - sizeof(*uh) == skb_shinfo(gso_skb)->gso_size) > > return __udp_gso_segment_list(gso_skb, features, is_ipv6); > > I guess checks should be needed for ipv6. > > Also it looks like this skips the CSUM_PARTIAL preparation, and possibly > break csum offload. > > Additionally I don't like the ever increasing stack of hacks needed to > let GSO_FRAGLIST operate in the most diverse setups, the simpler fix > would be disabling such aggregation. > > /P >