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.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
