From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by huchra.bufferbloat.net (Postfix) with ESMTP id 8C10621F1ED for ; Fri, 23 Aug 2013 08:05:55 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7NF5mFO015668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Aug 2013 11:05:49 -0400 Received: from localhost (ovpn-116-88.ams2.redhat.com [10.36.116.88]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7NF5kdV000750; Fri, 23 Aug 2013 11:05:47 -0400 Date: Fri, 23 Aug 2013 17:05:44 +0200 From: Jesper Dangaard Brouer To: Sebastian Moeller Message-ID: <20130823170544.696b1dda@redhat.com> In-Reply-To: <2D3FE3C2-AD17-4CDF-8DC3-D807B361EE66@gmx.de> References: <56B261F1-2277-457C-9A38-FAB89818288F@gmx.de> <2148E2EF-A119-4499-BAC1-7E647C53F077@gmx.de> <03951E31-8F11-4FB8-9558-29EAAE3DAE4D@gmx.de> <20130823092702.3171b5fd@redhat.com> <20130823131653.6aa3498f@redhat.com> <2D3FE3C2-AD17-4CDF-8DC3-D807B361EE66@gmx.de> Organization: Red Hat Inc. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] some kernel updates X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 15:05:55 -0000 On Fri, 23 Aug 2013 14:37:47 +0200 Sebastian Moeller wrote: > On Aug 23, 2013, at 13:16 , Jesper Dangaard Brouer wrote: > > > On Fri, 23 Aug 2013 12:15:12 +0200 > > Sebastian Moeller wrote: [...] > >>>>> Especially since the kernel already fudges > >>>>> the packet size to account for the ethernet header and then some, so this > >>>>> path should receive more scrutiny by virtue of having more users? > >>> > >>> As you mention, the default kernel path (not tc stab) fudges the packet > >>> size for Ethernet headers, AND I made a mistake (back in approx 2006, > >>> sorry) that the "overhead" cannot be a negative number. > >> > >> Mmh, does this also apply to stab? > > > > This seems to be two question... > > > > Yes, the Ethernet header size gets adjusted/added before the "stab" > > call. > > For reference > > See: net/core/dev.c function __dev_xmit_skb() > > Call qdisc_pkt_len_init(skb); // adjust Ethernet and account for GSO > > Call qdisc_calculate_pkt_len(skb, q); // is the stab call > > (ps calls __qdisc_calculate_pkt_len() in net/sched/sch_api.c) > > > > The qdisc_pkt_len_init() call were introduced by Eric in > > v3.9-rc1~139^2~411. > > So I look at 3.10 here: > > net/core/dev.c, qdisc_pkt_len_init > line 2628: qdisc_skb_cb(skb)->pkt_len = skb->len; > and in > line 2650: qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; > so the adjusted size does not seem to end in skb->len > > > and then in > net/sched/sch_api.c, __qdisc_calculate_pkt_len > line440: pkt_len = skb->len + stab->szopts.overhead; > > So to my eyes this looks like stab is not honoring the changes made in qdisc_pkt_len_init, no? At least I fail to see where > skb->len is assigned qdisc_skb_cb(skb)->pkt_len > But I happily admit that I am truly a novice in these matters and easily intimidated by C code. You are absolutely correct, and I were wrong. Guess I didn't read __qdisc_calculate_pkt_len() carefully enough, sorry. When stab is enabled, it will override the skb pkt_len. > > Thus, in kernels >= 3.9, you would need to change/reduce your tc > > "overhead" parameter with -14 bytes (iif you accounted encapsulated > > Ethernet header before) > > That is what I thought before, but my kernel spelunking made > me reconsider and switch to not subtract the 14 bytes since as I > understand it the kernel actively does not do it if stab is used. You are correct, and I was wrong. Good to have more eyeballs on the code :-) -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer