From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: inaccurate packet scheduling Date: Thu, 7 Feb 2013 17:13:27 +0100 Message-ID: <20130207161327.GA1619@minipsycho.brq.redhat.com> References: <1355849503.9380.37.camel@edumazet-glaptop> <20130102152601.GB1532@minipsycho.orion> <1357144482.21409.16876.camel@edumazet-glaptop> <20130108133038.GB1621@minipsycho.orion> <20130124080536.GA1598@minipsycho.orion> <1359036087.12374.2088.camel@edumazet-glaptop> <20130129122357.GC7571@minipsycho.orion> <1359475983.30177.2.camel@edumazet-glaptop> <20130130121447.GB1604@minipsycho.orion> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: edumazet@google.com, netdev@vger.kernel.org, kuznet@ms2.inr.ac.ru, jhs@mojatatu.com To: Eric Dumazet Return-path: Received: from mail-wg0-f45.google.com ([74.125.82.45]:64769 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754325Ab3BGQNd (ORCPT ); Thu, 7 Feb 2013 11:13:33 -0500 Received: by mail-wg0-f45.google.com with SMTP id dq12so2218867wgb.24 for ; Thu, 07 Feb 2013 08:13:31 -0800 (PST) Content-Disposition: inline In-Reply-To: <20130130121447.GB1604@minipsycho.orion> Sender: netdev-owner@vger.kernel.org List-ID: Wed, Jan 30, 2013 at 01:14:47PM CET, jiri@resnulli.us wrote: >Tue, Jan 29, 2013 at 05:13:03PM CET, eric.dumazet@gmail.com wrote: >>On Tue, 2013-01-29 at 13:23 +0100, Jiri Pirko wrote: >> >>> part of the commit message says: >>> >>> The bits per second on the wire is still 5200Mb/s with new HTB >>> because qdisc accounts for packet length using skb->len, which >>> is smaller than total bytes on the wire if GSO is used. But >>> that is for another patch regardless of how time is accounted. >>> >>> I believe that is a similar problem like ours. But looks like this >>> "another patch" never got in. >>> >> >>Hmm, I thought I addressed this in >> >>commit 1def9238d4aa2146924994aa4b7dc861f03b9362 >>Author: Eric Dumazet >>Date: Thu Jan 10 12:36:42 2013 +0000 >> >> net_sched: more precise pkt_len computation >> >> One long standing problem with TSO/GSO/GRO packets is that skb->len >> doesn't represent a precise amount of bytes on wire. >> >> Headers are only accounted for the first segment. >> For TCP, thats typically 66 bytes per 1448 bytes segment missing, >> an error of 4.5 % for normal MSS value. >> >> As consequences : >> >> 1) TBF/CBQ/HTB/NETEM/... can send more bytes than the assigned limits. >> 2) Device stats are slightly under estimated as well. >> >> Fix this by taking account of headers in qdisc_skb_cb(skb)->pkt_len >> computation. >> >> Packet schedulers should use qdisc pkt_len instead of skb->len for their >> bandwidth limitations, and TSO enabled devices drivers could use pkt_len >> if their statistics are not hardware assisted, and if they don't scratch >> skb->cb[] first word. >> >> Both egress and ingress paths work, thanks to commit fda55eca5a >> (net: introduce skb_transport_header_was_set()) : If GRO built >> a GSO packet, it also set the transport header for us. >> > > >I tried kernel with this patch in. I also ported >56b765b79e9a78dc7d3f8850ba5e5567205a3ecd to tbf. I'm getting always the >similar numbers with iperf. There must be something else needed :/ Any other ideas? > >Thanks > >Jiri