lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 26 Sep 2014 11:06:37 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Dave Taht <dave.taht@...il.com> Cc: Tom Herbert <therbert@...gle.com>, Jesper Dangaard Brouer <brouer@...hat.com>, Linux Netdev List <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Alexander Duyck <alexander.h.duyck@...el.com>, Toke Høiland-Jørgensen <toke@...e.dk>, Florian Westphal <fw@...len.de>, Jamal Hadi Salim <jhs@...atatu.com>, John Fastabend <john.r.fastabend@...el.com>, Daniel Borkmann <dborkman@...hat.com>, Hannes Frederic Sowa <hannes@...essinduktion.org> Subject: Re: [net-next PATCH 1/1 V4] qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE On Wed, 2014-09-24 at 19:58 -0700, Dave Taht wrote: > I have long hoped that the actual BQL limit in play would feed into > TCP small queues when there are a lot of flows to make each tcp > "small" queue gradually smaller... Yep, but what do you do if you have 64 TX queues, each one having different BQL limits ? This looks like a NP problem when you also have millions of tcp flows. Basically BQL limit is more a sign of local host being able to drain TX completions fast or not. Here at Google, we have a very tiny queue of at most 2 packets per flow, and srtt being in usec units gives us a very dynamic signal, based on end to end measures. I am experimenting moving TSQ processing from tasklet to workqueue, because we need faster response to {soft}irq when we so often enter TCP stack. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists