Wrong struct rtnl_htb_class and rtnl_ratespec?

[Thomas Graf]

On Thu, Nov 24, 2011 at 09:56:30PM +0200, Adrian Ban wrote:
> Can you confirm that this is the write order of struct rtnl_htb_class?
> 
> struct rtnl_htb_class
> {
>         uint32_t                ch_prio;
>         struct rtnl_ratespec    ch_rate;
>         struct rtnl_ratespec    ch_ceil;
>         uint32_t                ch_rbuffer;
>         uint32_t                ch_cbuffer;
>         uint32_t                ch_quantum;
>         uint32_t                ch_mask;
>         uint32_t                ch_level;
> };

This structure is only used by libnl internally. It's not
exported in the API and not used to format any messages
sent to the kernel.

> And in include/linux/pkt_sched.h I found:
> 
> struct tc_htb_opt {
>         struct tc_ratespec      rate;
>         struct tc_ratespec      ceil;
>         __u32   buffer;
>         __u32   cbuffer;
>         __u32   quantum;
>         __u32   level;          /* out only */
>         __u32   prio;
> };

This is the structure used to format the netlink messages
when talking to the HTB module.

> Also the tc_ratespec and rtnl_ratespec are different:
> 
> struct rtnl_ratespec
> {
>         uint8_t                 rs_cell_log;
>         uint16_t                rs_overhead;
>         int16_t                 rs_cell_align;
>         uint16_t                rs_mpu;
>         uint32_t                rs_rate;
> };

This is the internal representation of a rate specification.
This structure is never used to format, it's constructed
by copying each field individually in rtnl_copy_ratespec()

> First thing is that prio is always 0 even I set it.

How do you set the prio? Via rtnl_htb_set_prio()? If you
happen to set it internally you have to set the SCH_HTB_HAS_PRIO
flag to ensure the value is copied to the netlink message?

> Second I've found a strange behavior on a specific class which I've
> set to 128000 biti and the rate is around 4Mbit. Same values build
> with tc worked fine:

Seems that burst is not calculated correctly. I'll look into this.