[Make-wifi-fast] TCP performance regression in mac80211 triggered by the fq code

Dave Taht dave.taht at gmail.com
Tue Jul 12 09:03:42 EDT 2016

On Tue, Jul 12, 2016 at 2:57 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> Dave Taht <dave.taht at gmail.com> writes:
>>> As for why this would happen... There could be a bug in the dequeue code
>>> somewhere, but since you get better performance from sticking everything
>>> into one queue, my best guess would be that the client is choking on the
>>> interleaved packets? I.e. expending more CPU when it can't stick
>>> subsequent packets into the same TCP flow?
>> I share this concern.
>> The quantum is? I am not opposed to a larger quantum (2 full size
>> packets = 3028 in this case?).
> The quantum is hard-coded to 300 bytes in the current implementation
> (see net/fq_impl.h).

don't do that. :)

A single full size packet is preferable, and saves going around the
main dequeue loop 5-6 times per flow on this workload.

My tests on the prior patch set were mostly at the larger quantum.

> -Toke

Dave Täht
Let's go make home routers and wifi faster! With better software!

More information about the Make-wifi-fast mailing list