On 16-03-31 04:48 PM, 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...
MQ will assign a default qdisc to each txq and the default qdisc can be changed to htb or any other qdisc of your choice. > > 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. > Agreed. > 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. Nope sorry doesn't work that way unless you employ some sort of stacked netdevice strategy which does start to get a bit complex. The basic hint would be to stack some type of virtual netdev on top of a device and run the htb qdisc there. Push traffic onto the netdev depending on the class it belongs to. Its ugly yes. Noting all that I posted an RFC patch some time back to allow writing qdiscs that do not require taking the lock. I'll try to respin these and submit them when net-next opens again. The next logical step is to write a "better" HTB probably using a shared counter and dropping the requirement that it be exact. Sorry I didn't get a chance to look at the paper in your post so not sure if they suggest something similar or not. Thanks, John > > 2016-03-31 15:16 GMT-07:00 Cong Wang <xiyou.wangc...@gmail.com>: >> On Wed, Mar 30, 2016 at 12:20 AM, Michael Ma <make0...@gmail.com> wrote: >>> As far as I understand the design of TC is to simplify locking schema >>> and minimize the work in __qdisc_run so that throughput won’t be >>> affected, especially with large packets. However if the scenario is >>> that multiple classes in the queueing discipline only have the shaping >>> limit, there isn’t really a necessary correlation between different >>> classes. The only synchronization point should be when the packet is >>> dequeued from the qdisc queue and enqueued to the transmit queue of >>> the device. My question is – is it worth investing on avoiding the >>> locking contention by partitioning the queue/lock so that this >>> scenario is addressed with relatively smaller latency? >> >> If your HTB classes don't share bandwidth, why do you still make them >> under the same hierarchy? IOW, you can just isolate them either with some >> other qdisc or just separated interfaces.
