From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A9B243B260 for ; Mon, 6 Jun 2016 18:34:13 -0400 (EDT) Received: by mail-oi0-x22b.google.com with SMTP id e72so249320451oib.1 for ; Mon, 06 Jun 2016 15:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3Edgq7SsSHXkvv8U4ZALH47jvhkhOp5xqY94hUi9XBE=; b=EjdlsnTg0jErr+y/oLOGXVrfNGR/mXycoIEOBnts8sCLhhrTaIaDRqUFqPG1tnuhiM V5ELxB/R/ZJaT5LKXR6LX2iEmNWr50gla8zcDS4KE39v3TEJMbqwAvf5u0ntlpRxjujp qAQe8txwrFbv9HMheLphEsVw27cIIMdnMh49FPXTeBXYphhYXvBDyKG34ksuf0RM9llf nFJYy/hT39VDAAokef0qmh145btxKPJIOMaVmIKpkheJBv2p0kmZiHTjaijtNk10AHUb kMubZx+rBiT+cMeiiqD0JUf/9kOOT4HFJDZY924f/fZJVEh/UKaKEplmBogEowRolrH3 kyXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Edgq7SsSHXkvv8U4ZALH47jvhkhOp5xqY94hUi9XBE=; b=kIFkYqEKWIkkpp/3brJ39Tili/i64+xFWytrhWqVV3+jLo9FsBM1CBzn1dlDgTRzbI zYIM6h1+sNkWOg0DYNZIm4ZFQppeKOfIW5Ure2LX9Hkc/WTCEgGm0bUMru/uAV3l/QLj HBoiGSD4bWi6vSLnQcUi0bEhtoSnEdOCM+DAB6ZgvcEh63ft9X3FM0+snF2wSeyscQfL kZ1IMBBIilrRxvMGPoc/dbTepzTqJl5sowQuv+i1i7eyQScIJ4lhDKr6XpBp0doyKRi2 Qn2joIzL2SN5vZ10c3OxjTlRa9LZj9kctQdKjn2NyIJbRgsM2e06zCqj5MieYkVQOPJy 7iDA== X-Gm-Message-State: ALyK8tIhc3zYsPHmdQ+BGZQg4VjmgmU8ETxe95szYr38wJzI/bnOlYBXPpt48gzvv3wm2ftO4nBBskhjU4BHUQ== X-Received: by 10.202.65.133 with SMTP id o127mr10026216oia.43.1465252453106; Mon, 06 Jun 2016 15:34:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.19.37 with HTTP; Mon, 6 Jun 2016 15:34:12 -0700 (PDT) In-Reply-To: References: From: Benjamin Cronce Date: Mon, 6 Jun 2016 17:34:12 -0500 Message-ID: To: David Lang Cc: Dave Taht , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a113dc862f94a9e0534a3abea 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 22:34:13 -0000 --001a113dc862f94a9e0534a3abea Content-Type: text/plain; charset=UTF-8 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 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 > --001a113dc862f94a9e0534a3abea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Preliminary benchmarks of new network APIs like netmap are= showing 20mpps =C2=A0between guest and host for untrusted guests and 70mpp= s to trusted guests, and scales near linearly with more cores. With that ma= ny pps per guest, why not let the host do an AQM? High end service NICs sup= port multiple virtual devices where you can tell the NIC to evenly distribu= te bandwidth among the virtual devices. It's already mostly a solved pr= oblem, 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 2= 016, 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 a= t fairness between different VMs. they tell a VM that it has complete acces= s to the NIC for a time, then give another VM complete access to the NIC. A= t 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 packe= ts never get to the host OS.

The speed improvement is by bypassing the host OS and just having the VMs d= eliver 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

--001a113dc862f94a9e0534a3abea--