On Tue, Jul 12, 2016 at 2:57 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > Dave Taht <dave.t...@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! http://blog.cerowrt.org -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
