[..] Which means the classid is not reset by exec(). 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 b
* jamal <1115035838.8929.236.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-02 08:10 Absolutely, given it is requested by the user. My main concern are dependencies on classid invisble to the user. What about
[..] Basically, something along those lines (eg struct tca_pkt_info) in which the tcf_result is one of the components should do it. I would be satisfied with this being the structure in the ->act() p
* jamal <1115207194.7665.109.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-04 07:46 Sounds good. I have no objections but fail to see why we want to clear it anyway?
* jamal <1115211549.7665.140.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-04 08:59 OK, so we're not talking about a reset in action_exec() but rather in tc_classify() or enqueue()?
* Thomas Graf <20050504132822.GB18452@xxxxxxxxxxxxxx> 2005-05-04 15:28 Sorry, little bit to vague, what I mean is before the first call to tc_classify() or enqueue() on a new device.
* jamal <1115213600.7665.166.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-04 09:33 Yes this solves the case for dummy devices etc but how would this cause a reset on the way from ingress to egress?
If the verdict is not to reset, there should be no clearing of those fields from ingress -> egress until the skb is either freed or someone else along the path resets it. Cloning or copying inherits.
* jamal <1115214782.7665.184.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-04 09:53 I guess not but we might have a different understanding of when to reset. From my point of view the only reason to reset any
* jamal <1115216629.7906.4.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-04 10:23 As long as we can't find a way to have a well defined local scope which is both easy to implement and easy to understand for t