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

[Xin Xie <xiexinet@gmail.com>]

> 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