On 16-06-17 06:03 PM, Eric Dumazet wrote:
On Fri, Jun 17, 2016 at 2:59 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
Generally speaking I worry about we change multiple fields in a struct
meanwhile we could still read them any time in the middle, we may
get them correct for some easy case, but it is hard to insure the
correctness when the struct becomes large.
I am thinking to make more tc actions lockless, so this problem
comes up immediately for other complex cases than mirred.
I certainly wont object to a patch.
Also note that instead of RCU with a pointer and the usual kfree_rcu() stuff,
we now can use seqcount_latch infra which might allow to not increase
memory foot print.
Given an update/replace of an action is such a rare occassion, what
is wrong with init doing a spin lock on existing action?
Sure, there is performance impact on fast path at that point - but:
as established update/replace is _a rare occassion_ ;->
cheers,
jamal
