Re: [Cake] faster scheduling, maybe

[David Lang <david@lang.hm>]

That works as long as the right answer is to evenly share the bandwidth between 
the VMs.

But what if one VM is running a single elephant flow while another VM is a VoIP 
server with hundreds of connections? Is it still correct to split the bandwidth 
evenly between the two?

David Lang

On Mon, 6 Jun 2016, Benjamin Cronce wrote:

> Preliminary benchmarks of new network APIs like netmap are showing 20mpps
> between guest and host for untrusted guests and 70mpps to trusted guests,
> and scales near linearly with more cores. With that many pps per guest, why
> not let the host do an AQM? High end service NICs support multiple virtual
> devices where you can tell the NIC to evenly distribute bandwidth among the
> virtual devices. It's already mostly a solved problem, just some people
> reinventing the wheel. I know FreeBSD is currently looking at adding netmap
> to connect the guest to the host so the guests can do line-rate 10Gb and
> almost 40Gb.
>
> On Mon, Jun 6, 2016 at 1:48 PM, 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.
>>
>> David Lang
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>>
>