From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 6FE463B2A4 for ; Fri, 14 Apr 2017 19:38:52 -0400 (EDT) Received: by mail-wr0-x233.google.com with SMTP id l28so56942720wre.0 for ; Fri, 14 Apr 2017 16:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K0+6fKn2RHgOcy5s4kIYtq8EadjJNKZFGy8VUCy9aMA=; b=k0X4UNFyc6PjP69QrNJMobSdei4qxtq0HAi+5H3Hxd6D++H7Gobdc4rsWMbg6SBq5p DBgcVo34deUWgwu+h7//BZo6seqPlgTvIixSSUamYyBtwlyIZvkEKHh/bvt3bGY0vVI0 91gppUFl+Aw/oRP7jljvqE5ZGpKwIFE/4xwCxInFoj2xRjaxstcpX5KzqTzSwGQxAKbD dBJKPwFZ1jtSCJgd/90JOD8slJDm1jxylwkNJH4lqMXus7eAZwb8NpWJKwrk7K1dTZ2R Td16KbMHClWGa79BLmkbrMTdMl49sj5hz2GpYTMUC/DrsKPJ1B3PYA+XXTFGVGte6XYe L2pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K0+6fKn2RHgOcy5s4kIYtq8EadjJNKZFGy8VUCy9aMA=; b=T1+pA+Pap+SSFjo4yfj6o14PBHkOhPYS18ZQg4Rwm6sLyzmfOFD6ptPUaPcDarC7f/ k5UQhifwEQYmjGLRB2uV60X8s+JFLd1SsF0XO+jFtIuPq0lHJtAcHVdCm2fnJruczXk0 NHrXum9hzBpT2GiC7HvSreOghvhSR3vdT+tkQS7jDKkHLiDIbjreYJmWbKO7628+Ysf/ BVTrZeN8qgBYK/BNdhCsaismu8evEMsQMAzoi6Ue9dEQpbyH0HYbIKHftr3qLunhv/OF iUs35m4AkpFnPr+thU0U1C7cRqpsivB5qhdDeq6Lw8SfI9QlDxA8eE2t7Ci2qfnGQxzQ fmRQ== X-Gm-Message-State: AN3rC/6TlgNL3+eu+QJ8t4H1irtkTTFmtNiqwhLUpIoXSHQNw/bGwY5O IT9TgzoyKPZlw1Gn/U8f2JeNE6DnYA== X-Received: by 10.223.163.133 with SMTP id l5mr752980wrb.119.1492213131512; Fri, 14 Apr 2017 16:38:51 -0700 (PDT) MIME-Version: 1.0 References: <1492192844.10587.78.camel@edumazet-glaptop3.roam.corp.google.com> In-Reply-To: <1492192844.10587.78.camel@edumazet-glaptop3.roam.corp.google.com> From: Aaron Wood Date: Fri, 14 Apr 2017 23:38:41 +0000 Message-ID: To: Eric Dumazet Cc: bloat Content-Type: multipart/alternative; boundary=f403045f1570a20e55054d28f12d Subject: Re: [Bloat] sch_fq pacing rate: Xbps, but at which layer in the network stack? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 23:38:52 -0000 --f403045f1570a20e55054d28f12d Content-Type: text/plain; charset=UTF-8 Eric, Thanks for the confirmation of that. So application pacing of say 8Mbps (1000 packets at 1000 bytes each), is equivalent to 8.3-8.4Mbps at the interface (depending on ip header options) So anyone planning on calling setsockopt() needs to keep that in mind? Or is that calculated correctly for an application? -Aaron On Fri, Apr 14, 2017 at 11:00 Eric Dumazet wrote: > On Thu, 2017-04-13 at 20:12 -0700, Aaron Wood wrote: > > When I was testing with my iPerf changes, I realized that the sch_fq > > pacing (which in iperf is set via setsockopt()), is pacing at a > > bandwidth that's set at a pretty low level in the stack (which makes > > sense). This is different from the application pacing that iperf does > > (which is pacing the goodput). > > > > > > But it's not clear to me where the X bps determination is being made. > > My current guess is that it's at the interface level (since that's > > where sch_fq is), and so it's approximately "bytes on the wire", minus > > preambles and inter-packet spacing, and whatnot. And so it's > > including all the 802.x headers involved (vlan tags, qos tags, > > source/dest macs, etc). Is this correct? > > > Like other qdisc having rate limits (TBF, HTB ....), FQ sees packets > with all headers (including Ethernet one) > > This is why the default quantum is 3028, which is exactly 2 regular > Ethernet frames (MTU=1500 + 14 bytes of Ethernet header) > > If you have VLAN tag, it is generally not included in the calculation, > as many devices provide 'hardware tagging'. > > > > > > --f403045f1570a20e55054d28f12d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric,

Thanks for the confirmation of that.

So application pac= ing of say 8Mbps (1000 packets at 1000 bytes each), is equivalent to 8.3-8.= 4Mbps at the interface (depending on ip header options)

So anyone pl= anning on calling setsockopt() needs to keep that in mind? Or is that calc= ulated correctly for an application?

-Aaron
On Fri, Apr 14, 2017 at 11:00 Eric Dumazet <eric.dumazet@gmail.com> wrote:<= br>
On Thu, 2017-04-13 at 20:12 -0700, = Aaron Wood wrote:
> When I was testing with my iPerf changes, I realized that the sch_fq > pacing (which in iperf is set via setsockopt()), is pacing at a
> bandwidth that's set at a pretty low level in the stack (which mak= es
> sense).=C2=A0 This is different from the application pacing that iperf= does
> (which is pacing the goodput).
>
>
> But it's not clear to me where the X bps determination is being ma= de.
> My current guess is that it's at the interface level (since that&#= 39;s
> where sch_fq is), and so it's approximately "bytes on the wir= e", minus
> preambles and inter-packet spacing, and whatnot.=C2=A0 And so it's=
> including all the 802.x headers involved (vlan tags, qos tags,
> source/dest macs, etc).=C2=A0 Is this correct?
>
Like other qdisc having rate limits (TBF, HTB ....), FQ sees packets
with all headers (including Ethernet one)

This is why the default quantum is 3028, which is exactly 2 regular
Ethernet frames (MTU=3D1500 + 14 bytes of Ethernet header)

If you have VLAN tag, it is generally not included in the calculation,
as many devices provide 'hardware tagging'.





--f403045f1570a20e55054d28f12d--