Traffic shaping - class ID 16bit limit?

Hello everyone,

the question is simple: What should I do if I need to have more than
2^16 subclasses of a classful queuing discipline (in, say, hfsc or
htb)?

I bumped into this problem while writing some kind of traffic shaping
software and thinking about scalability. As there still are other ways
to have more than 64k "classes" (like grouping some subclasses into
separate qdiscs), those ways have significant drawbacks (require more
tc-filter rules and decisions, generally more processing power, and
the structure is quite hard to maintain).

Technically the ClassID seems to be "hardcoded" as a 16bit value, but
after some source searching, I haven't found any good reason for it to
be 16-bit only.

I understand that those ID's are usually handled together with another
16bit Qdisc ID, which would add up to a quite big number (possibly
unpleasant on some architectures) if those were both 32bit.

I also completely understand that in most cases of common usage
there's absolutely no need to have this big amount of subclasses, but
on the other hand there's still no reason to have "64k classes enough
for everyone". :D

Of course if there's some obvious method to solve this, or a patch, or
some kind of workaround that I haven't found, please let me know about
it, I will happily use it.

Thanks for any suggestions,
Mirek Kratochvil

On Thu, 25 Aug 2011 18:28:01 +0200
Miroslav Kratochvil [off-list ref] wrote:

Technically the ClassID seems to be "hardcoded" as a 16bit value, but
after some source searching, I haven't found any good reason for it to
be 16-bit only.

Granted it was a poor choice in the initial design.
It is wired into the API and changing it would be quite painful.

You might be able to do the same thing by splitting traffic
into multiple virtual devices (dummy or ifb) and then doing
another layer.

quoted

Technically the ClassID seems to be "hardcoded" as a 16bit value, but
after some source searching, I haven't found any good reason for it to
be 16-bit only.

Granted it was a poor choice in the initial design.
It is wired into the API and changing it would be quite painful.

I was feeling something like that would come.

If I get it correctly, the API change would consist of:

- some netlink protocol change
- slight modification of qdisc_class_hash
- modifications in all (four?) hierarchical schedulers
- tiny expansion of userspace tc utility

which isn't that painful (except for the CBQ part), but I'm probably
missing something, and presumably the change would take some time to
get mainstream -- probably way more time than writing a hfsc clone
that is controlled using some other interface than tc/netlink. :(

(but hey! I have a topic for school work!)

You might be able to do the same thing by splitting traffic
into multiple virtual devices (dummy or ifb) and then doing
another layer.

My scenario looks pretty simple, mostly like a big hashing filter
attached at the device root, flowid'ing the stuff to leaf classes.
Could you please provide some simple illustration of splitting that
into multiple devices? I guess that the main problem with this
approach would be that my subclasses usually don't share anything in
common, especially not any pretty IP prefixes that would allow good
splitting.

Anyway, thanks very much for response!

-mk

On Thu, 25 Aug 2011 19:06:58 +0200
Miroslav Kratochvil [off-list ref] wrote:

quoted

quoted

Technically the ClassID seems to be "hardcoded" as a 16bit value, but
after some source searching, I haven't found any good reason for it to
be 16-bit only.

Granted it was a poor choice in the initial design.
It is wired into the API and changing it would be quite painful.

I was feeling something like that would come.

If I get it correctly, the API change would consist of:

- some netlink protocol change
- slight modification of qdisc_class_hash
- modifications in all (four?) hierarchical schedulers
- tiny expansion of userspace tc utility

And all the magic compatiablity layers to make old code
work with new code.

On Thu, 2011-08-25 at 09:39 -0700, Stephen Hemminger wrote:

Granted it was a poor choice in the initial design.
It is wired into the API and changing it would be quite painful.

You should be able to have infinite queues if you use the 
hierachies. i.e each hierachy should expose a new 16 bit
namespace. 

cheers,
jamal

From: Miroslav Kratochvil <redacted>
Date: Thu, 25 Aug 2011 19:06:58 +0200

quoted

quoted

Technically the ClassID seems to be "hardcoded" as a 16bit value, but
after some source searching, I haven't found any good reason for it to
be 16-bit only.

Granted it was a poor choice in the initial design.
It is wired into the API and changing it would be quite painful.

I was feeling something like that would come.

If I get it correctly, the API change would consist of:

- some netlink protocol change
- slight modification of qdisc_class_hash
- modifications in all (four?) hierarchical schedulers
- tiny expansion of userspace tc utility

There is precedence as we had to make the routing table rule ID larger
and were successfully able to do so using netlink attributes.