Re: patch: Action repeat

[jamal <hadi@cyberus.ca>]

On Sat, 2005-30-04 at 22:08 +0200, Thomas Graf wrote:

> I've been using tc_classid to communicate between ingress and egress
> without the need for netfilter but this is something personal. This
> meant to remove the tc_classid = 0 in tcf_action_exec and a have
> smallish action set it at ingress to pick it up again with the meta
> ematch at egress.
> 

I think we may have to define what the scope of classid is. It seems to
me the scope needs to be _local_ to either ingress or egress. 
OTOH, something like a fwmark is _global_. 
At least this is what my thoughts were when doing that piece.
Using those rules, the situation Patrick describes on violates this
(because stolen packets still maintain the classid), yours doesnt -
unless we change the scope of classid. 


> > I see the issue with classid leaking - perhaps specific actions could
> > reset it when they steal packets? We should also reset it if the packet
> > is stolen.
> 
> Definitely.

Just thinking about that: _exec() can reset classid if packet is stolen
and not transfer it back to classifier.
I think the forward path is to have the actions reset it. We would just
have to make it the rule described somewhere or have a macro someone
call every time they steal a packet... 

> I'm not yet certain on this subject, I have a strong feeling that
> something like tc_classid will be needed but not as in its current
> use. Can we postpone this for 1-2 weeks so I can submit my new
> ematch patches? This would give us something to use as a basis for
> a discussion.

If we are going to redefine the scope of where a classid applies, then
we can discuss it any time.

cheers,
jamal