> > The simplest way to fix the CR is let snoop to check the LSO > > information with the packet and avoid warning it. But I'm not sure > > it's enough. Since LSO packets will be segmented by the NIC hardware > > so on the wire there are only MTU-size packets. Are there suers who > > expect to have a option for snoop to see the "expected packets on the > > wire"? For example, `snoop -?` to parse the LSO packet header to > > multiple regular headers that are expected to be seen on the wire? > > I think snoop should only report what it really sees. For physical > devices, on the tx side, snoop can never see post-segmentation packets > on the wire. I don't think snoop should make a guess and report what it > has imagined to the users. > > > > It gets a little bit complex when we implement LSO on top of VNICs, as > > is still being discussed. When snooping a VNIC created on e1000g, > > should the snoops be seeing original LSO packets as sent to e1000g or > > post-segmentation packets as seen on the wire? Any thoughts? > > If "snoop -d vnic0", I think it should report original LSO packets. If > the real traffic passes through e1000g, "snoop -d e1000g0" should report > the real packets that are passed to e1000g (if e1000g LSO is disabled, > it should show regular Ethernet frames to users).
Yes -- and FWIW we do something similar when hardware checksums are enabled (snoop simply reports what's in the packet, even if it's invalid). That said, there should be some facility that allows snoop to know this is an LSO packet and make this clear to the user examining the dump. Of course, we could also disable LSO in this case, but I think that would be a mistake because it's likely the problem the user is trying to troubleshoot is related to LSO -- and thus by disabling LSO we are only making their life harder. (There is intentionally no supported administrative mechanism for disabling LSO; we need to keep it that way.) -- meem _______________________________________________ networking-discuss mailing list [email protected]
