| 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 linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Apr 2016 15:46:21 -0700 From: Michael Ma <make0818@...il.com> To: Eric Dumazet <eric.dumazet@...il.com> Cc: Cong Wang <xiyou.wangcong@...il.com>, Linux Kernel Network Developers <netdev@...r.kernel.org> Subject: Re: qdisc spin lock 2016-04-08 7:19 GMT-07:00 Eric Dumazet <eric.dumazet@...il.com>: > On Thu, 2016-03-31 at 16:48 -0700, Michael Ma wrote: >> I didn't really know that multiple qdiscs can be isolated using MQ so >> that each txq can be associated with a particular qdisc. Also we don't >> really have multiple interfaces... >> >> With this MQ solution we'll still need to assign transmit queues to >> different classes by doing some math on the bandwidth limit if I >> understand correctly, which seems to be less convenient compared with >> a solution purely within HTB. >> >> I assume that with this solution I can still share qdisc among >> multiple transmit queues - please let me know if this is not the case. > > Note that this MQ + HTB thing works well, unless you use a bonding > device. (Or you need the MQ+HTB on the slaves, with no way of sharing > tokens between the slaves) > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bb1d912323d5dd50e1079e389f4e964be14f0ae3 > > bonding can not really be used as a true MQ device yet. > > I might send a patch to disable this 'bonding feature' if no slave sets > a queue_id. > > So there is no way of using this MQ solution when bonding interface is used, right? Then modifying HTB might be the only solution?
Powered by blists - more mailing lists