From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CDE1B3B260 for ; Mon, 6 Jun 2016 14:48:55 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u56ImqrW027120; Mon, 6 Jun 2016 11:48:52 -0700 Date: Mon, 6 Jun 2016 11:48:52 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht cc: cake@lists.bufferbloat.net In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Cake] faster scheduling, maybe X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:48:56 -0000 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