> 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
