On 2024/10/28 18:41, Anthony J. Bentley wrote:
> Stuart Henderson writes:
> > We do support TSO on some em(4). Though, while I am not certain, I don't
> > think we do on I219-V... Anthony, do you still have that machine available?
> > Can you do an "ifconfig em hwfeatures" please so we can be sure?
>
> $ ifconfig em0 hwfeatures
> em0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500
> hwfeatures=36<CSUM_TCPv4,CSUM_UDPv4,VLAN_MTU,VLAN_HWTAGGING> hardmtu
> 9216
> lladdr 94:c6:91:a3:6d:8a
> index 2 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect (1000baseT full-duplex)
> status: active
> inet 10.0.0.15 netmask 0xffffff00 broadcast 10.0.0.255
Thanks. So, as expected, no TSO here.
So to summarize what is clear from the recent findings:
- em(4) is doing something that trips problems
- either the path from LRO->TSO, or something with LRO itself,
is doing something that trips problems
and (mentioned elsewhere but including it for tech@ readers) -
mbuf handling in wg(4) is broken.
So on some systems disabling tcplro on interfaces ("ifconfig
vio0 -tcplro", "ifconfig ix0 -tcplro" etc) may help work around
the problem. On others (like the em case) that won't help.
With the em case with no TSO, possibly running wg(4) in a VM and
disabling tcplro on vio in the guest may help sidestep the wg(4)
problems. (And if it's not that, net.inet.tcp.tso=0 might be worth
a try).
