On Sun, 2005-01-05 at 01:58 +0200, Thomas Graf wrote:
> * jamal <1114900485.8929.171.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-04-30 18:34
[..]
> > Perhaps we can reuse classid by flagging somewhere?
> > A good place to do it is tc_verdict. There a few bits still left.
> > We could set a bit to say the meaning of classid to be global vs local.
>
> Sounds good to me, I'm not quite sure if I still have a good enough
> picture of your action code. Let's assume we have ematches and an
> action setting the classid at ingress. The action sets the above flag
> to state the global scope.
Which means the classid is not reset by exec().
> The packet passes the stack and the
> classid gets copied into the new encapsulated packet. On the egress
> device we have something like a nop action assigning the classid
> to res->classid. How do we make sure that the classid remains
> untouched even if the packet passes a dummy device in between having
> actions configured? Can we we still have functional actions on
> this dummy device?
I would say that if dummy changes it because of a policy, then thats a
fair deal. i.e
filter blah blah \
action add meta classid global :23
I am beginning to think that perhaps classid should stay as a local
scope metadata and what Patrick suggested maybe the way out. Although i
have to admit I dont like a generic function to have a parameter that
only a very small set of users find useful. If we are going to allow a
structure to be passed back and forth, perhaps it should also carry
other things (in addition to _result). Need to think a little.
cheers,
jamal
|