From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 BE12621F279 for ; Tue, 16 Jun 2015 11:32:28 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so17756505pac.2 for ; Tue, 16 Jun 2015 11:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=0IRMwDQvrJHGALtEQcO0IFM356n+xHbNSi5TbXlZMHg=; b=iq0XEr9aPSVaaLLwEwVmA30DvbPIaxbV4fgUGmbzj51t17f8Q2bm4aQr3glVimlSlj ++hDFdmC2OU5QhF9zBvatYJILBHHsR+Vdtms4Zq5mNRdFLMLSGQXAkTRzXTJDaA5Bqty cPjitCPdw8in/j4yBcQb/lixC73S/k2nrN28r9QsjfgECtEu72b4nt0eiEX/4kK4vJ5A i/R2BId8Dv0cAzzbBM5Y6AkctPqw1doIo6eyMBIS3KnGyoc4ZTqGOahCUbAtXsJ5z3su v+cRd5M5kK6ygMLRp+fF7r8w/0UCG45wT1gfXWJ6cdYGnPPewTvhX3c/7xdv8+QCaAOU TLcA== X-Received: by 10.68.250.194 with SMTP id ze2mr3136038pbc.24.1434479547639; Tue, 16 Jun 2015 11:32:27 -0700 (PDT) Received: from [172.30.42.71] (c-71-202-136-89.hsd1.ca.comcast.net. [71.202.136.89]) by mx.google.com with ESMTPSA id ae9sm2174822pac.25.2015.06.16.11.32.25 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2015 11:32:26 -0700 (PDT) Message-ID: <1434479544.27504.195.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Dave Taht Date: Tue, 16 Jun 2015 11:32:24 -0700 In-Reply-To: References: <20150616173306.GA9097@sesse.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 18:32:56 -0000 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. > > 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. http://www.spinics.net/lists/netdev/msg251368.html u32 val = 1000000; setsockopt(sockfd, SOL_SOCKET, SO_MAX_PACING_RATE, &val, sizeof(val)); Can it be simpler than that ? (In C I mean...)