> 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.
Not only. GRO can be disabled, and patch 1 does that. Patch 3 is for
GSO skbs that arrive without any GRO. The case is the one from the
cover letter: a software PRP RedBox on a Linux host, with containers
or VMs on the SAN side and two NICs for the PRP LANs.
container/netns host PRP RedBox
prp0-peer ---- veth ---- prp0-int (interlink RX)
|
split GSO into frames
|
sequence number + RCT
/ \
LAN A LAN B
When the container sends a large TCP or UDP skb, veth hands it to
prp0-int as one GSO skb. Nothing on that path segments it, and GRO on
prp0-int plays no role. The same happens with virtio or tap. PRP must
give every wire frame its own sequence number and RCT, so patch 3
splits the skb before that. A NIC with GRO_HW that cannot be switched
off is the second case. Local traffic from the HSR master is handled by
removing the GSO features, so the core segments it before
ndo_start_xmit().
> 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?
The bridge only came up in the v6 discussion as a comparison: when a
bridge forwards a GSO skb to a physical port, the TX path segments it,
but it cannot add a PRP RCT and sequence number to each segment. We do
not use a bridge inside the ring.
--
Xin
