[Cake] openwrt build with latest cake and other qdiscs

[Sebastian Moeller]

Hi Jonathan,


On May 13, 2015, at 08:43 , Jonathan Morton <chromatix99 at gmail.com> wrote:

>>> I would humbly suggest that we should just get a numerical option for cake to specify the overhead...
>> 
>> That is in the plans, along with keywords in tc as mnemonics for the most common configurations.
> 
> 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)?


Also from:
static inline u32 cake_overhead(struct cake_sched_data *q, u32 in)
{
        u32 out = in + q->rate_overhead;
        
        if(q->rate_flags & CAKE_FLAG_ATM) {
                out += 47;
                do_div(out, 48);
                out *= 53;
        }
        
        return out;
}       

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 know we generally recommend not to use GRO oat least on slow links, but maybe cake should do the right thing even if encountering offloads?

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”. That said autadjusting for GRO does seem to make some sense, even the light version of just getting the number of actual ethernet packets hiding in the GRO aggregate an multiplying the rate_overhead with that number, or probably better just multiply out by the number of packets in the aggregate (to make sure we honor AAL5’s nasty integer number of cells per packet rule). I am out of my league here, but I have a hunch this might be something useful for the cake audience and the goal to keep configuration simple.

> 
> The iproute2 support isn’t as complete as I’d eventually like.  However, you can specify a numerical overhead (positive or negative, within sane limits) independently of whether ATM framing compensation is turned on or off.

	Excellent, so this will also work for PTM encapsulation and additional ISP mandated overheads.

> 
> There are also two “easy mode” keywords: “raw” is equivalent to “noatm overhead 0”, and “conservative” means “atm overhead 48”.  The latter will almost certainly overestimate the actual overhead.

	Great, this is probably the most user friendly set of keywords to start out with, at worst overestimating the overhead can make the shaper assume a packet is double its actual wire size and hence wasting 50% of bandwidth, but the larger the packet the smaller the wasted percentage of bandwidth get, and users can iteratively decrease the overhead to find the sweet spot for their link. So I fully endorse these two settings (for what my endorsement is worth ;) )

> 
> The help text for cake also now indicates the default options more clearly.
> 
> Also pushed is a one-line build fix for iproute2.

	This is really looking great, I will need to switch my router over to this (or better get a new router so the old one can stay configured as is, as family friendly back-up ;) )

Best Regards
	Sebastian

> 
> - Jonathan Morton
>