Re: [PATCH 3/4] net: hsr: unfold GSO super-packets at the forward entry

[Xin Xie <xiexinet@gmail.com>]

> So veth. The test suite is using veth I don't remember that it was (is)
> a problem there. But then there is no TCP.
> Wouldn't it be also a problem if you attach veth interface to a bridge
> and that large TCP skb would have to leave the bridge via a physical
> port?

When a bridge forwards a GSO skb from veth to a physical port, the
outgoing TX path handles segmentation. validate_xmit_skb() checks
whether software segmentation is needed. The networking core performs
software segmentation as needed and can use hardware segmentation
offload when available for that skb.

The software HSR/PRP path needs to split the GSO skb earlier. Each
segment needs its own sequence number and HSR tag or PRP trailer.
We add these before calling dev_queue_xmit() on the lower device.
The normal TX segmentation code cannot create these per-frame
HSR/PRP fields for us.

TCP is the case I reproduced, but this is not limited to TCP. UDP
GSO skbs can also pass through veth without being segmented.
Passing normal PROFINET RT or GOOSE frames through veth does not
make them GSO skbs. Patch 3 skips segmentation for these frames.
They still follow the normal HSR/PRP forwarding path.

> This does not sound like it is limited to hsr. I think it deserves a
> helper similar to skb_linearize().

Patch 3 already uses the common __skb_gso_segment() helper, then
passes each segment through normal HSR/PRP forwarding. Do you mean
a new common wrapper around this helper?

-- 
Xin