From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (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 EFF1221F291 for ; Wed, 24 Sep 2014 15:48:48 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id w61so6151168wes.35 for ; Wed, 24 Sep 2014 15:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NT03HkEluR8FQkkXPDjF0ZRUTZM2qeDxwUdM+lcX6q0=; b=gHRY1EgkyZBy52o9o9dyYllUlUSx3iIdEC0PzK3hIP8Oww7+5W1897nJQkGAkj6sr3 F5pk6EVjcUIgzj8pdu8kiJEjpb0aIiSlebrdeiih7hDn5aWcItbotDXoe7dG/sdFd8Nc kZzk0JzjpKWs7APS4ysKe/FXmmTMVKIb1YhmH34KLulYtCQDrBZT9e3bomg93+LxXNsx yKTIqLvlVlnKUx9nJagbpZGfj3ANTVYXtSNN1M6FOJkyMQdhkhgh2J3pHSvxaEYMpNX1 G5idvgEf5AP0VEpK3RbafIgDWJ9MgSnDcdOIWNEXmBy4aMvxncN5mrA2+LLG5zMbC+Ng PKnA== X-Received: by 10.180.98.131 with SMTP id ei3mr21135846wib.46.1411598926117; Wed, 24 Sep 2014 15:48:46 -0700 (PDT) Received: from [192.168.0.3] (27.24.189.80.dyn.plus.net. [80.189.24.27]) by mx.google.com with ESMTPSA id fl6sm1099578wib.21.2014.09.24.15.48.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Sep 2014 15:48:45 -0700 (PDT) Message-ID: <54234A50.7050102@gmail.com> Date: Wed, 24 Sep 2014 23:48:48 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Sebastian Moeller References: <541C9527.1070105@yescomputersolutions.com> <541DA8B5.70701@gmail.com> <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> <54201F8B.70408@yescomputersolutions.com> <3136C05A-8069-4F04-B352-69A2BF3578FC@gmx.de> <5420AAA1.70203@yescomputersolutions.com> <54218D48.1020906@gmail.com> <5421C490.3020104@gmail.com> <54228C40.4050605@gmail.com> <16C372C8-70C4-4E62-A059-BF2C65A88CF0@gmx.de> In-Reply-To: <16C372C8-70C4-4E62-A059-BF2C65A88CF0@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "lartc@vger.kernel.org" , Alan Goodman , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections 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: Wed, 24 Sep 2014 22:49:17 -0000 Sebastian Moeller wrote: >> Maybe you mean overhead calculated by a script? > > Well in cerowrt’s SQM-scripts we expose the stab options so users can > take link layer and overhead into account. If you naively determine > the overhead, either with the help of the scrips I posted earlier or > by looking it up on a table (if the encapsulation options are known) > you will end up not handling the kernel’s auto-added overhead well. > Currently SQM scripts does not expose PPP devices only ge00 > (ethernet) so -14 seems currently the best recommendation in > combination with “please test”. Oh, OK - I know nothing about wrt. > What I am curious after your message > is what happens if the kernel terminates a pppoe connection but is > connected to a “modem” via ethernet, what does the kernel do. And > thanks to your pointers I know have an idea of how to test that ;) Well I can't say I know - testing is always best. I think we are "seeing" skbs just as they enter an interface - so what form they take depends on the particular interface they have just been made for. It's possible to have multiple pppoes/vlans on an eth and use the eth normally at the same time. What you see I suppose depends on where you are "attached". I guess shaping a pppoe on the eth rather than on the actual ppp is doable with a bit of filtering - in which case you may need to allow for the +14 macs/ethertype and that 8 ppp are already in the payload - a totally untested theory :-) >> On ppp skb->len = ip len >> >> On eth skb->len = ip len + 14 >> >> On vlan skb->len = ip len + 18 > > So this is the information I actually wanted to find and then somehow > thought qdisc_pkt_len_init() was the place. Do you by chance have any > pointer where this assignment is handled? No, sorry I don't know the code.