From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 04ADF21F514 for ; Tue, 16 Jun 2015 12:33:02 -0700 (PDT) Received: by obbsn1 with SMTP id sn1so18614342obb.1 for ; Tue, 16 Jun 2015 12:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+AOOtaCws3zXeu+BXef3xS9XNkhDLuGLFEl1pkRSHD8=; b=YUUg05W2RHQ5hHtTsNJUxHOx3FTbVkPdw953ppCQHhdF46OjZod3oApVmuEgp27vzA y4g/T9cYXv2DSBeSBvJF9OHMpTbkThwt9sboktQwxZz1z/dcgP1ndPG0892BheqPFah+ S8gtvbmtnF/U6Sd+af7AVJv3FWgNGX61n0SwTj81csucapfqMoVmuoGEdBIo+wCyZLvs m7HCTUKMt1iQQ0lZU/5gCvwbkCxYm2twe+Z/D/UClHGEVaYYODrve3rQIC1njO8O9scv Emu7eC6ct4jJDyJr9qII+zYaZ1/w3GIH2TDVsw/Srp7wZUd8FnS5G4MEJDSX2GuxAalh ATyg== MIME-Version: 1.0 X-Received: by 10.60.147.194 with SMTP id tm2mr1544789oeb.75.1434483182088; Tue, 16 Jun 2015 12:33:02 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Tue, 16 Jun 2015 12:33:02 -0700 (PDT) In-Reply-To: <1434479544.27504.195.camel@edumazet-glaptop2.roam.corp.google.com> References: <20150616173306.GA9097@sesse.net> <1434479544.27504.195.camel@edumazet-glaptop2.roam.corp.google.com> Date: Tue, 16 Jun 2015 12:33:02 -0700 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] sweeping up the bloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 19:33:31 -0000 On Tue, Jun 16, 2015 at 11:32 AM, Eric Dumazet wro= te: > On Tue, 2015-06-16 at 10:53 -0700, Dave Taht wrote: > >> But guidelines on how to configure it in applications are missing. > > Well, you know the optimal rate -> set it. It is that simple. > > If not, leave this to TCP stack. > >> As >> are when where and how to implement it in DCs, handheld clients, >> internal servers and hosts, home routers, slow networks, VMs, and bare >> metal servers. >> >> Quic does pacing, so far as I know, entirely in userspace, or does it >> rely on sch_fq to do so? Should a VOIP app or server like freeswitch >> use it? > > A Quic server handles thousands (millions ?) of flows. Having one kernel > socket per flow would be way too expensive. > > (And BTW, rx path in UDP is not optimized for 4-tuple hashing). > > There are 2 hash tables, one lookup on destination_IP:destination_port, > and one on *:destination_port. > > For Quic server, all sockets would share same keys. thank you. I am watching the progress on the github libs for quic with great anticipation. >> >> I see in the kernel support for sk_pacing_rate, and max_pacing_rate >> and it is unclear how/when those options can be of aid and set. > > Really ? > > You haven't try hard, and this is quite upsetting given your concerns. Consider the last few weeks as "trying harder". While I have great enthusiasm for all the improvements in e2e stuff, my time for any of it shrank considerably while keeping a roof over my head with largely irrellevant work, teasing the long tail of folk that still believed in reno, bringing up new devices that were 2.6 based (sigh), and stabilizing openwrt stuff for a new re-deployment on 3.18, that had significant breakages in babel (1.6.1 is due tonight), dnsmasq (2.73 just released) and ongoing issues in hnetd, and dhcp-pd. toke's testbed remains at 3.14. My principal server is still 3.9. In recent months I have established 3.19 servers all over the world to test with, but have not got around to doing anything truly coherent with them. Next step was to add them to the flent pool. been distracted by "cake". but my ongoing, massive, step, has been to try to assemble sufficient solutions and resources to tackle make-wifi-fast at all layers 0-10, which has eaten most of my "spare" time for many, many months now. Jim is focused on other things, and I long ago hit "overwhelm" with the resources I had. Only now, am I trying to catch up on all the good stuff that has happened e2e since I last could pay any attention, and it seemed like a better idea to instead be trying to find people willing to step up on all other fronts in the bufferbloat battle. I gotta admit, bufferbloat.net was a lot more fun 4+ years ago. I stopped scaling shortly before we finalized cerowrt. I am all in favor of a top down level perspective from you and all others of this effort as to what we (And I) should be prioritizing in the future. Closing up shop entirely is also an option. For fun, these days, I hack on FPGAs. > http://www.spinics.net/lists/netdev/msg251368.html Although *I* read all your commits every month (which used to be daily), I only grepped the kernel for "pacing" just now. There is for example, nothing on it in Documentation/networking . There are no patches in open source code enabling it that I can find, actually using SO_MAX_PACING_RATE. It IS in my glibc headers, but TCP_NOTSENT_LOWAT is not, which is sort of what sparked this thread - what good had happened since I last paid attention, and how far had it spread? So I think a little more outreach and example patches for various common applications is needed. From everybody. > u32 val =3D 1000000; > setsockopt(sockfd, SOL_SOCKET, SO_MAX_PACING_RATE, &val, sizeof(val)); Thx. flent and/or netperf could use a fixed rate sender test exercising thi= s. > Can it be simpler than that ? (In C I mean...) Heh. Nope. > > > --=20 Dave T=C3=A4ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast