On Fri, 2019-12-06 at 10:12 +0100, Johannes Berg wrote: > On Fri, 2019-12-06 at 09:41 +0100, Johannes Berg wrote: > > Maybe somehow TSO is interacting badly with the TXQs and the tracking > > here, since TSO makes the traffic *very* bursty? A 64k packet in the > > driver will typically expand to 9 or 10 A-MSDUs I think? > > No, that all seems well. Without TSO (with the trivial mac80211 patch to > let me turn it off with ethtool) I get about 890Mbps, so about 5% less. > That's not actually *that* bad, I guess due to software A-MSDU in > mac80211, but it's not really the right direction :) > > Changing wmem_max/tcp_mem to outrageous values also didn't really make > any difference. > > I guess it's time to see if I can poke into the TCP stack to figure out > what's going on... Sadly no functioning kprobes on the system ... bpftrace -l lists them, but can't actually use them. If I also change net.ipv4.tcp_limit_output_bytes to an outrageous value (10x) I can recover a bit more than half of the performance loss with TSO disabled, but it makes no real difference with TSO enabled. Either way, what bothers me somewhat is that the backlog fluctuates so much. Sometimes I see a backlock of 2MB or more, while it *still* manages to go completely empty. Shouldn't I expect the steady state to have a somewhat even backlog? Why does this vary so much? johannes
