On Thu, 2019-12-05 at 18:12 +0100, Toke Høiland-Jørgensen wrote: > > I'm on mobile, so briefly: > > What you're describing sounds like it's TCP congestion control kicking > in and throttling at the stack. Agree, though need to think about the UDP scenario more. It's faster, but that's expected since it doesn't have the ACK backchannel, and it's not that *much* faster. > The "new flows" increasing is consistent with the queue actually > running empty (which you also see in the warnings). Oh, right ok. That makes sense, it just loses info about the flow once the queue is empty. > My hand-wavy explanation is the the TCP stack gets throttled and > doesn't get going again quickly enough to fill the pipe. Could be a > timing thing with aggregation? As I said, hand-wavy ;) So I should need deeper *hardware* queues to make up for the timing? Thing is, sometimes I even see the queue empty, then there are *two* MTU-sized frames, and then it's empty again - all the while there are only ~40 frames on the hardware queue. You'd think the higher layer would, once it starts feeding again, actually feed more? Hmm. Actually, I wonder why I'm not seeing TSO, something to check tomorrow. johannes
