From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Wed, 24 Sep 2014 22:48:48 +0000 Subject: Re: [Cerowrt-devel] Correctly calculating overheads on unknown connections Message-Id: <54234A50.7050102@gmail.com> List-Id: References: <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> In-Reply-To: <6DF5DFA0-D88E-470E-ACB6-37703EA964E7@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Sebastian Moeller wrote: >> Maybe you mean overhead calculated by a script? > > Well in cerowrt=92s 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=92s 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 =93please test=94. 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 =93modem=94 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=20 form they take depends on the particular interface they have just been=20 made for. It's possible to have multiple pppoes/vlans on an eth and use the eth=20 normally at the same time. What you see I suppose depends on where you=20 are "attached". I guess shaping a pppoe on the eth rather than on the=20 actual ppp is doable with a bit of filtering - in which case you may=20 need to allow for the +14 macs/ethertype and that 8 ppp are already in=20 the payload - a totally untested theory :-) >> On ppp skb->len =3D ip len >> >> On eth skb->len =3D ip len + 14 >> >> On vlan skb->len =3D 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.