On Mon, Jul 6, 2015 at 2:12 PM, Jamal Hadi Salim <j...@mojatatu.com> wrote:
> on mirred: > The main thing that is read-write is the stats. lastuse timestamp > as well, but that one doesnt have to be accurate (used mainly > to help decide when to flush out policies). so the lock around > all that code is not necessary. > > BTW: I was wondering based on what you said earlier on false sharing > if tcf_common can be re-arranged to avoid that? Not really : You would still have a stall on lastuse ultimately, even if it sits in a cache line of its own. I mentioned that it shared a cache line to explain with "perf" was showing the stall on reading another field. > > For mirred, you may have to add for overlimit stat in the common > structure (we should really increment drop stats when we return > TC_ACT_SHOT). > > Having said that: we want to maintain the fact that an action > instance (based on index) can be used across different policies. > i dont see any issue with the way you are proceeding for that > to continue to work. i.e i can say something like: > - create an action to redirect or mirror to port blah index 10 > - create filter one on eth1 with 1 of the actions being mirred index 10 > - create filter two on eth0 with 1 of the actions being mirred index 10 I do not see any issues either. > > On IFB: > we use tasklets originally to avoid re-ordering. I think tasklets would > still be useful to keep, with each tied to a queue? Sure. We do not care about reorders if packets were delivered to different RX queues. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
