[Cake] openwrt build with latest cake and other qdiscs

[Jonathan Morton]

>> I’ve just pushed support for an overhead parameter; both cake itself and the iproute2 module.  I took the opportunity to put in a minor optimisation for the cell-framing compensation as well.
> 
> 	Great, thanks a lot. I have a question though: http://lxr.free-electrons.com/ident?i=psched_l2t_ns basically does the same operation, but slightly different:
>               DIV_ROUND_UP instead of do_div((n+d-1), d)
> What is the kernel policy here, reuse specialized macros or rather code more readable (with slight redundancy)?

It looks as though the DIV_ROUND_UP() expands to exactly the same code, except that a plain division is used instead of do_div().  The latter includes a conversion to multiplying by the inverse on ARM, when the divisor is a constant (which it is), since ARM doesn’t have a hardware integer divide.  (AArch64 does.)

With that said, I haven’t closely examined the resulting assembler.

I’m also not going to use psched_l2t_ns(), because I use the corrected packet length for other purposes than just time.  It also fails to support negative overheads, which can occasionally occur when using IPoA.

> It seems clear that cake does fully rely on the supplied overhead, unlike htb which will automatically add ethernet overhead and an estimate? of the additional header GRO packets drag in, see:
> http://lxr.free-electrons.com/source/net/core/dev.c#L2744

I can’t figure out the connection between HTB and that code.  Also, that appears to be GSO, not GRO.  I’m not precisely sure what the difference is, but I’d hazard a guess that GSO is outbound, GRO is inbound.

Frankly, I hate having to deal with packet aggregates in the core network stack.  Device drivers can aggregate if that makes sense for the hardware, but I’d much rather that was kept out of my qdisc.  Peeling is on the agenda; that’ll make sure we are dealing with actual, individual packets when we need to.  Certainly when dealing with cell-framing overhead, we *always* need to know individual packet sizes.

> I actually like that cake does not try to auto-adjust the overhead by itself, since the kernel does this automatically for an ethernet link, but not say for a PPPoE interface, making it a bit tricky to recommend the proper encapsulation to ATM users, “use 40 if you shape on the pppoe-wan interface but 26 if you shape on the wan interface directly is a sure way to confuse people”.

I consider that a user-interface problem, as well as reflecting a general problem with PPPoE.  Actually, PPPoE has *never* been user-friendly; it outright sucks in all respects.  I can’t think of a single reason to use PPPoE instead of PPPoA.  AFAIK, all Finnish and most British DSL ISPs use either PPPoA or bridging; I’ve only personally encountered PPPoE in the US.

To help reduce confusion, it would probably be best to offer consistent advice on which interface to shape and how much overhead to account for there.  I think shaping the traffic that actually goes over the link is more correct than shaping the traffic that goes to the modem (which might include some management traffic that doesn’t go on the wire).  So you should shape on the PPPoE interface and add the full 40 bytes there.  Happily, this advice is also safe if the user accidentally selects the wrong interface, since 40 bytes is conservative for the Ethernet interface.

Anyway, user-interface problems are best solved in userspace.  Cake’s internal implementation is thus kept simple and numerical.  The tc module now supports that directly, and more user-friendly support can be added either there or in external scripts, or some combination of the two.

 - Jonathan Morton