Re: Correctly calculating overheads on unknown connections

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.