Re: [Cake] faster scheduling, maybe

[Dave Taht <dave.taht@gmail.com>]

On Mon, Jun 6, 2016 at 11:48 AM, David Lang <david@lang.hm> wrote:
> On Mon, 6 Jun 2016, Dave Taht wrote:
>
>> http://info.iet.unipi.it/~luigi/papers/20160511-mysched-preprint.pdf
>
>
> I don't think so.
>
> They don't even try for fairness between flows, they are just looking at
> fairness between different VMs. they tell a VM that it has complete access
> to the NIC for a time, then give another VM complete access to the NIC. At
> best they put each VMs traffic into a different hardware queue in the NIC.
>
> This avoids all AQM decisions on the part of the host OS, because the
> packets never get to the host OS.
>
> The speed improvement is by bypassing the host OS and just having the VMs
> deliver packets directly to the NIC. This speeds things up, but at the cost
> of any coordination across VMs. Each VM can run fq_codel but it's much
> corser timeslicing between VMs.


Well, the principal things bugging me are:

* that we have multi-core on nearly all the new routers.
* Nearly all the ethernet devices themselves support hardware multiqueue.
* we take 6 locks on the qdiscs
* rx and tx ring cleanup are often combined in existing drivers in a
single thread.

The chance to rework the mac80211 layer on make-wifi-fast (where
manufacturers are also busy adding hardware mq), gives us a chance to
rethink how we process access to these queues.

>
> David Lang



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org