Re: [PATCH] Traffic control cgroups subsystem

["Ranjit Manomohan" <ranjitm@google.com>]

On Wed, Jul 23, 2008 at 3:34 PM, Patrick McHardy <kaber@trash.net> wrote:
> Andrew Morton wrote:
>>
>> On Tue, 22 Jul 2008 10:44:18 -0700 (PDT)
>> Ranjit Manomohan <ranjitm@google.com> wrote:
>>
>>> @@ -359,7 +370,12 @@ static int flow_classify(struct sk_buff *skb, struct
>>> tcf_proto *tp,
>>>                        classid %= f->divisor;
>>>
>>>                res->class   = 0;
>>> -               res->classid = TC_H_MAKE(f->baseclass, f->baseclass +
>>> classid);
>>> +
>>> +               if (key == FLOW_KEY_CGROUP_CLASSID)
>>> +                       res->classid = TC_H_MAKE(f->baseclass, classid);
>>> +               else
>>> +                       res->classid = TC_H_MAKE(f->baseclass,
>>> +                                                f->baseclass + classid);
>>
>> This causes a warning:
>>
>> net/sched/cls_flow.c: In function 'flow_classify':
>> net/sched/cls_flow.c:344: warning: 'key' may be used uninitialized in this
>> function
>>
>> that warning is a non-issue if we happen to know that f->nkeys can
>> never be zero.  I don't know if that is guaranteed at this code site?
>
> It is by the flow_change() function, but special casing the
> CGROUP_CLASSID is not acceptable anyway. There should be no
> need for that, a simple linear mapping to classids is done
> by default in mapping mode, the sk_cgroup_classid simply
> shouldn't include qdisc IDs.

I did not want to special case it but I want an identity mapping not a
linear one.  For some reason a baseclass of X:0 is not allowed, and
there does not seem to be a clean way to get a 1-1 mapping (tc.classid
-> X:tc.classid). I would have to workaround it by using a baseclass
of the form X:Y and then subtracting Y from the value written to
tc.classid which seemed very non intuitive.

Any particular reason for this restriction? Am I missing any other
technique of getting a 1-1 mapping using the flow classifier?

-Thanks,
Ranjit

>