All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Xin Xie <xiexinet@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	edumazet@google.com, pabeni@redhat.com, horms@kernel.org,
	andrew+netdev@lunn.ch, shuah@kernel.org, kees@kernel.org,
	petr.wozniak@gmail.com, qingfang.deng@linux.dev,
	fmaurer@redhat.com, luka.gejak@linux.dev,
	xiaoliang.yang_1@nxp.com, skhawaja@google.com,
	liuhangbin@gmail.com, stable@vger.kernel.org,
	sdf.kernel@gmail.com
Subject: Re: [PATCH 1/4] net: hsr: fix packet drops caused by GRO superpackets
Date: Wed, 23 Sep 2026 12:32:38 +0200	[thread overview]
Message-ID: <20260923103238.cg3tr_40@linutronix.de> (raw)
In-Reply-To: <7c09a44a-19d9-43f5-a852-12f5b6579641@gmail.com>

On 2026-09-19 01:46:34 [+0200], Xin Xie wrote:
> On 14/08/2026 03:21, Jakub Kicinski wrote:
> > 1) could you explain in more detail why GRO is breaking things?
> > GRO shouldn't merge packets with different L2/L2.5 and packets
> > with trailers?
> The reproducer is plain SAN traffic entering a PRP RedBox's
> interlink: matching Ethernet headers, no RCT yet, so GRO can merge it.
> PRP then appends one RCT to the aggregate, using its length for
> LSDU_size and assigning one sequence number. If the aggregate LSDU
> exceeds 4095, the 12-bit field truncates it. Later TCP segmentation
> cannot generate per-segment RCTs. An aggregate left unsegmented may
> instead be dropped for exceeding the lower device's frame-size limit.
> Our wire captures showed segments without RCTs and duplicate delivery
> through the two LANs.Disabling interlink GRO raised single-stream TCP 
> throughput from 27-37 Mbit/s to about 94 Mbit/s on the 100 Mbit/s rig.
> 
> > 2) the code seems inspired by LRO but LRO also has
> > NETIF_F_UPPER_DISABLES. This change looks rather incomplete.
> > Calling it "best effort" seems like an excuse.
> NETIF_F_UPPER_DISABLES prevents a lower's ethtool request from
> overriding an upper's LRO-off policy. GRO is outside that mask and
> remains changeable; extending the global mask would affect other
> stacked devices too. Patch 1 sets the GRO-off default, while patch 3
> segments plain, trailer-free aggregates before tagging, including
> when GRO is re-enabled or GSO arrives directly. GRO_HW can also be
> fixed on, so feature disabling alone cannot exclude all aggregates;
> device-specific hardware-coalesced formats remain outside v6's
> segmentation guarantee. I should have explained this distinction
> from LRO explicitly.

Would adding a NETIF_F_HSR_SLAVE flag to slave device(s) and then filter
invalid flags in netdev_fix_features() fix this? This should help
against enabling and add a warning if a flag can not be removed.

A netdev_change_features() might do the job then.

Sebastian

  reply	other threads:[~2026-09-23 10:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-09 12:14 [PATCH net v6 0/4] net: hsr: fix GRO/GSO super-packet handling Xin Xie
2026-08-09 12:14 ` [PATCH 1/4] net: hsr: fix packet drops caused by GRO superpackets Xin Xie
2026-08-14  1:21   ` Jakub Kicinski
2026-08-17 15:38     ` Xin Xie
2026-09-18 23:46     ` Xin Xie
2026-09-23 10:32       ` Sebastian Andrzej Siewior [this message]
2026-09-24 21:16         ` Xin Xie
2026-08-09 12:14 ` [PATCH 2/4] net: hsr: shrink seqnr_lock to sequence counter updates Xin Xie
2026-08-10  2:23   ` Hangbin Liu
2026-09-23 10:37   ` Sebastian Andrzej Siewior
2026-09-24 21:22     ` Xin Xie
2026-08-09 12:14 ` [PATCH 3/4] net: hsr: unfold GSO super-packets at the forward entry Xin Xie
2026-09-23 10:43   ` Sebastian Andrzej Siewior
2026-09-24 21:26     ` Xin Xie
2026-09-25  8:29       ` Sebastian Andrzej Siewior
2026-09-25  9:52         ` Xin Xie
2026-09-28  6:38           ` Sebastian Andrzej Siewior
2026-09-28  9:42             ` Xin Xie
2026-09-28 10:12               ` Sebastian Andrzej Siewior
2026-08-09 12:14 ` [PATCH 4/4] selftests: net: hsr: cover GSO super-packets on PRP slave ingress Xin Xie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260923103238.cg3tr_40@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fmaurer@redhat.com \
    --cc=horms@kernel.org \
    --cc=kees@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=luka.gejak@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petr.wozniak@gmail.com \
    --cc=qingfang.deng@linux.dev \
    --cc=sdf.kernel@gmail.com \
    --cc=shuah@kernel.org \
    --cc=skhawaja@google.com \
    --cc=stable@vger.kernel.org \
    --cc=xiaoliang.yang_1@nxp.com \
    --cc=xiexinet@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.