On Sat, Feb 10, 2024 at 10:22:03PM +0100, Claudio Jeker wrote:

> > The watchdog timeouts seen with em(4) tso enabled [1] do only happen when
> > em_tso_setup() receives an empty tcp frame, so the payload is zero.
> > I can understand that the hardware fails when we ask to tso zero bytes
> > of payload -- This shouldn't happen.
> > 
> > Those empty tcp frames are only arriving in em_tso_setup() when ix(4)
> > forwards packets.  I suspect the issue somewhere in
> > 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_ix.c.diff?r1=1.196&r2=1.197
> > 
> > But I don't understand this LSO code good enough to spot what might go
> > wrong there.  I can see that when this happens, ix(4) forwards a packet
> > with 60 bytes (vlan header + 2 bytes payload?) m_pkthdr.len, and 1 byte
> > m_pkthdr.ph_mss.  Why this results in em_tso_setup() receiving an
> > packet with 54 bytes (no payload), I don't understand.
> 
> This is because the minimal Ethernet packet is 64 bytes but since vlan
> header is used it is reduced to 60. There is a trailer in this packet
> since the payload (IP len) is less than 60 / 64 bytes.
> 
> 54 bytes is probably 12 (ETH HDR) + 20 (IP) + 20 (TCP) + 2 Payload

Isn't ETH HDR still 14 bytes (without vlan)?  My calculation was

14 (ETH HDR) + 20 (IP) + 20 (TCP) = 0 Payload 
 
> > The updated diff skips empty tcp frames em_tso_setup().  With that the
> > watchdog timeouts reported by Hrvoje are gone.  But obviously it's not
> > the solution for the issue in ix(4).
> 
> Yes, this smells like a ix(4) LRO bug that may need a software workaround
> in ix(4) itself.