Re: [PATCH net v7 3/4] net: hsr: segment GSO before per-frame forwarding

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-10-09 22:13:23 [+0200], Xin Xie wrote:
> HSR/PRP require a tag/RCT and sequence number for each wire frame.
> Adding them to a GSO aggregate before segmentation cannot provide
> valid per-frame metadata.
> 
> Use the core GSO segmenter before normal per-frame processing.
> Each segment follows the usual local-delivery and forwarding paths.
> Remove GSO_MASK types from the master's hw_features so core TX also
> segments local traffic before ndo_start_xmit().
> 
> Classify by inner protocol, not ingress port. Use the core's bounded
> VLAN decoder for 802.1Q, 802.1AD and nested or accelerated tags.
> Reject inner HSR/PRP aggregates, unreadable fragments and undecodable
> headers. Also reject trailing bytes beyond a known nonzero IP length:
> otherwise an old PRP sender's erroneous whole-aggregate RCT becomes
> transport payload. This check also rejects locally destined malformed
> inputs that the base kernel accepted. Zero IP lengths and GSO_PARTIAL
> are left to the segmenter because they provide no full IP extent for
> this check.
> 
> The preceding ordered-consumer patch is required for per-segment
> local numbering. Charge the worker budget by the actual segment count,
> or one on failure, and count each rejected input once through core
> per-CPU statistics on its entry device.
> 
> Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")

I've been re-reading the old mails. The whole thing is needed for GSO
when it can not be disabled, right? And VETH interface has been named as
an example.
There was also a bridge device. With HSR you form a ring. With a bridge
you attach other (physical) devices within the ring. This does not sound
like real life use-case. Do I miss something?

> Signed-off-by: Xin Xie <xiexinet@gmail.com>

Sebastian