On Sat, 2016-06-18 at 09:45 -0400, Jamal Hadi Salim wrote: > 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_ ;->
The potential 'problem' is not the write side, but the read side. If you read say 3 values <A, B, C> you might want to read them in a consistent way, instead of <new_A, old_B, old_C>
