From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) (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 B356B3BA23F for ; Fri, 14 Aug 2026 14:11:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786716685; cv=none; b=hFmO7IH8fJrQUvEh47oqebUDoVUksiJ5JVMCkkX5qQZEbiL/3BdPxdhtcUKeiCnqIiuvs9X1cbFEueQP0Xp8p3ELxoo0+pSnIhszyco6CXbc0vDVilJqM3TLWZ0vbAOKSvhNu60o6S1zUmfCXwD1fmI/1qJzj9jAz7IKYfejddQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786716685; c=relaxed/simple; bh=esHp+c46NHWZqA28j+A1hShu8h8QA8zkHE3mnLSTAGM=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=Z7e3Ji0gILp2ZuR+W9lHjtmcKjaHPG8thm6vAFbRDlsnYhE24ELgMgh/JFjEsyBcNlLEHIUrbdp8ZiKWQIeAbChfGxRoJdCb7c10WC5Os6Cdg8yBqBpwScUQnLicxotENkT/Q7xdAjQf1z9LVLBEv9vNTnhZKbsTKr+WkcmgLPk= 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=N2fyyG4P; arc=none smtp.client-ip=209.85.128.171 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="N2fyyG4P" Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-836cd7310f4so15196487b3.2 for ; Fri, 14 Aug 2026 07:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786716681; x=1787321481; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=a6Tr53R1oyo5DF6Qa5INdwaCZq7w4p85RVWoodqQmV8=; b=N2fyyG4PK+eV6k0QED0gabpFP8ZTevaXgAI+1p1WurVlMt1KzCF07m7y79XBGRwnf3 TI/QK0HyGl9djAfsvktTO/+uEnjhgpFvFBHUjejr43vnNwzFYoxWhq149Fo9kRmZltX3 4zMKpy9EH3VkslEXO9rKb0aXr0v9FQdAdf2s5OYWjqFMbe5qGbxoAD6LOwoD4+IbACGp XFHNMOR8v1leC1CY81LXLBhcEBxOaWpdssEg1IFLam6JfU2Jyl7Lg4fL9JWGodNLEF3C KXUXHZRPG8w/ZJcS2HCdZHBkTQVYmNtTxsGXaohjEyfY5tAiUn2Pg2RKKE4TV65iWupL 6k8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786716681; x=1787321481; h=content-transfer-encoding:content-type: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 :content-type; bh=a6Tr53R1oyo5DF6Qa5INdwaCZq7w4p85RVWoodqQmV8=; b=swNem10wu0Wm9G0LDF4gABqiodGvdOuMbUTOKEUeYJK1Ac2Jn4pyCHX1qSbdg2nRDq XshQyeigMVL7OcrJuZRZmN96Ir7XuYMmUqizkzMjxjtic9LpM0hCmfYzXYJ1dG3NJcy/ xdkIalX8YB7+JCi6eQaupaYbSKkLhs4gSjuPZ5N3wlDIV5J3NF83sJ0hFMnXYd1Gez6P TUfbOKVp+dDdQmcPg4wKBJzvpzeqtusOLr7Gw5+F94sBktDx1usVoPmut1WhG5oWhK0f DKzz5pREtApK+/XOnXm8SqNHsYVTAQa03yJE1eZCY1TaKtqnrZnhaEN7GZXuJiFuvWm2 khWg== X-Forwarded-Encrypted: i=1; AHgh+RqQI8QBDkCb9SvApesoElrD+YiMAz7GWXlQHCwnO1plxBlC8xvmol6fz1haQYS3VQP/PgFO3pwMBqURe0E=@vger.kernel.org X-Gm-Message-State: AOJu0YwQREyH0+d+TS0UuS1gn+tsXrYuUy6VKN/EcrgKqa8Z0y2feQZv Fa20uyViUr1bSOcxebd5CHzUCat/TV620UEEsrve/yV7n8/KvG8HRgDi X-Gm-Gg: AR+sD13kedokXHrR76yH1qgGfAHbFVgz8RZhNGBK8vWiDZVP8kNilpUwDjPG6vqoH2k AO9al4dhAQQWnjrsnu4qC+5p+0isk2R5e0BCQKC/HVbKJ3RSwXiBgRwUhfcI5PVsI41OhwGyVs3 2yYarxL3viWG0IfaqtBPgrgU62Rola9xBPKOtF9GacLp6W16V5VkhG2ixKxqNeeT+/NjZrsu1pk h2f3Cbw8BneI1ERPg3pGzsDyRsQV/2s7YSJhkTkM3UpSIrSeq2rBe0lqVcH1eCYpH+nDowUiyjQ cVVIfvVSd2l51BDlnvX5gDbQokbxN7Qscr+Og3npZgykODLbuWDnTP/7AJLH5GHW2M5zPTdZjCf BiC6OXJ11Vid8Gs814fagqt4BF9XVhPCF4idWao/1s00uJURer1CqjiHU+zEPc5/J5sAVxELSda gIROY4UCI6OOcyN9RE69i+6TTIv+zs7l3G8gZr21ez34x7ckmtySqkaFMJgZ01+sxYV+2hp5sAO EEWhvwyQV9qGdk7cnZdw3uEIiw8WZk77kPvgv4bOjxZOl4= X-Received: by 2002:a05:690e:1c0a:b0:66c:4163:c4e6 with SMTP id 956f58d0204a3-66c72c75dc1mr2777139d50.26.1786716681408; Fri, 14 Aug 2026 07:11:21 -0700 (PDT) Received: from gmail.com (250.4.48.34.bc.googleusercontent.com. [34.48.4.250]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-66c79390cd0sm895319d50.19.2026.08.14.07.11.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 07:11:19 -0700 (PDT) Date: Fri, 14 Aug 2026 10:11:19 -0400 From: Willem de Bruijn To: =?UTF-8?B?Wmhhb3BpbmcgU2h1ICjoiJLlj6zlubMp?= , "willemdebruijn.kernel@gmail.com" Cc: "kuniyu@google.com" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "imv4bel@gmail.com" , "eilaimemedsnaimel@gmail.com" , "alice@isovalent.com" , =?UTF-8?B?SFcgSGUgKOS9leS8nyk=?= , =?UTF-8?B?SGFpanVuIExpdSAo5YiY5rW35YabKQ==?= , =?UTF-8?B?SXZlbiBZYW5nICjpmLPlhYkp?= , "horms@kernel.org" , "kuba@kernel.org" , =?UTF-8?B?WGlheXUgWmhhbmcgKOW8oOWkj+Wuhyk=?= , "pabeni@redhat.com" , "edumazet@google.com" , "willemb@google.com" , "netdev@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , =?UTF-8?B?TGFtYmVydCBXYW5nICjnjovkvJ8p?= , "matthias.bgg@gmail.com" , "davem@davemloft.net" , AngeloGioacchino Del Regno , "sd@queasysnail.net" , "ncardwell@google.com" Message-ID: In-Reply-To: References: <20260813014056.160533-1-zhaoping.shu@mediatek.com> <0e1f71c4417099399eda78fd2a082b2444e42af9.camel@mediatek.com> Subject: Re: [PATCH net v3] net: gro: Fix nesting of TCP GSO SKBs in skb_gro_receive_list() 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 > > > > Would it be better to test skb_is_gso(skb) and only skip fraglist > > > > GRO > > > > for HW-GRO skbs, rather than disabling it for all skbs? > > > > > > Yes, for tethering packets, HW-GRO skbs are aggregated by > > > skb_gro_receive(), while others go through fraglist GRO. However, > > > care > > > must be taken to avoid packets arriving out of order. I will work > > > on > > > it and submit V4. > > > > Oh right. > > > > As long as the choice is only between fraglist GRO or not fraglist > > (rather than GRO or bypass GRO), it should not introduce any new > > reordering concerns. > > > > But the decision cannot be made based on skb_is_gso(skb) of an > > arriving skb. Because when such a HW-GRO skb arrives a SW GRO context > > in fraglist mode may already have been opened, and it is too late to > > convert that to non-fraglist. > > > > So essentially HW-GRO and fraglist are mutually exclusive. > > > > > > > > > > If treating the features as mutually exclusive, another option > > > > would > > > > be to replace these datapath checks with disabling one at > > > > configuration > > > > time, in netdev_fix_features. > > > > > > > > > > If V4 work well, there will be no need to check netdev->features. > > > Linux kernel GRO will be more robust and able to handle scenarios > > > where both NETIF_F_GRO_HW and NETIF_F_GRO_FRAGLIST are enabled. > > > > What is your plan for v4? > Based on kernel 7.2.0.rc7 code: > Add logic in tcp4/6_check_fraglist_gro() as follow: > if an arriving skb is the first packet in the GRO list. > NAPI_GRO_CB(skb)->is_flist = !sk && !skb_is_gso(skb); > > /* > * Otherwise, the arriving skb is not the first packet, which means > * that struct sk_buff *p exists. > */ > if (!skb_is_gso(skb) || !NAPI_GRO_CB(p)->is_flist) { > /* Aggregate the skb using p's GRO method. */ > NAPI_GRO_CB(skb)->is_flist = NAPI_GRO_CB(p)->is_flist; > } else { > NAPI_GRO_CB(skb)->is_flist = 0; > /* Flush p and start a new GRO list using the non-fraglist > method. */ > } > > Another code change in > tcp_gro_receive() { > ... > if (unlikely(NAPI_GRO_CB(p)->is_flist)) { > ... > /* if aggregate method changed, flush current gro list > */ > flush |= NAPI_GRO_CB(skb)->is_flist != NAPI_GRO_CB(p)- > >is_flist; > if (flush || skb_gro_receive_list()) > ... > } > } > > After this change: > - NETIF_F_GRO_HW and NETIF_F_GRO_FRAGLIST are no longer mutually > exclusive. > - In tethering scenarios, TCP fraglist GRO applies only to consecutive > non-GSO skbs(!skb_is_gso(skb)). > others will adopt skb_gro_receive() path. > > Please provide some suggestions on the changes above. Should I prepare > V4 patch based on these changes? Thanks. This sounds good to me. The risk is that GRO might be less effective at coalescing, if HW-GRO and non HW-GRO packets alternate regularly. The alternative to make HW-GRO and fraglist GRO mutually exclusive does not have that problem, but on the flipside cannot use the fraglist optimization (esp for forwarding path). So no free lunch. Either works.