On Mon, Jun 6, 2016 at 11:48 AM, David Lang <[email protected]> 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 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
