Re: dummy as IMQ replacement

[Thomas Graf <tgraf@suug.ch>]

> Let the meta action do that. Just set the skb->tc_classid in my opinion;
> recall we can change classid now ..

True, I don't really care but it's already quite confusing. The priority
of the packet is described in viarous field depeding on which qdisc/cls
being used, we have skb->priority with sch_prio, tc_index for dsmark
and cls_tcindex and now tc_classid directly.  Some even use u32 to
match on DSCP and set a nfmark.  I can already feel the perfect confusion
once we open up access for rt_classid, realm and other routing fields.
I'm always aiming for easy to understand solutions, this doesn't mean
it to be simple. Why is nfmark so heavly used? Because it's damn simple
to undertand, you can set and read it and that's it. The only thing one
has to care about is to make sure that is actually gets set before it being
read and to make sure all userspace apps read it in the same base ;->
(This is basically one of the issue in usability, the lack of clearliness
in what base number are read the displayed. Often they get displayed in
hex without a 0x prefix but are read with strtol(...,0) resulting in
a decimal reading if no prefix is specified)

Long rant short statement, I'm pleading for a generic way to transfer
such things between a classifier and a qdisc because it's simply
easier to explain and use.

... eaction meta set tc_index ip_saddr_proto_hash
... qdisc sfq tcindex-hash

where ip_saddr_proto_hash is not a variable but rather a special meta
value calulated in the kernel.

> You can let the user define that via tc but have a default;
> eg: 
> tc dev eth0 add sfq ematch
> tc dev eth0 set sfq pertub xxx
> 
> match u32 ...
> ematch sfq
> ematch meta classid 1:2 
> eaction meta set tcindex 101
> eaction meta set fwmark ..

I think we're on the same road or at least going into the same direction.
However I'm not sure whether it's a good to have ematches return
some values besides true/false. I'd rather like to see an eaction store
it in the skb and the sfq catching it up again. Of course we can have the
userspace part be configured within the sfq.