Re: [PATCH net] net_sched: act_mirred: full rcu conversion
flat view
From: John Fastabend <john.fastabend@gmail.com>
Date: 2016-09-12 15:35:02
On 16-09-11 11:12 PM, Cong Wang wrote:
On Fri, Sep 9, 2016 at 8:52 AM, John Fastabend [off-list ref] wrote:quoted
On 16-09-08 10:26 PM, Cong Wang wrote:quoted
On Thu, Sep 8, 2016 at 8:51 AM, Eric Dumazet [off-list ref] wrote:quoted
On Thu, 2016-09-08 at 08:47 -0700, John Fastabend wrote:quoted
Works for me. FWIW I find this plenty straightforward and don't really see the need to make the hash table itself rcu friendly. Acked-by: John Fastabend <redacted>Yes, it seems this hash table is used in control path, with RTNL held anyway.Seriously? You never read hashtable in fast path?? I think you need to wake up.But the actions use refcnt'ing and should never be decremented to zero as long as they can still be referenced by an active filter. If each action handles its parameters like mirred/gact then I don't see why its necessary.This is correct, by "read" I meant "dereference", the tc actions are now permanently stored in hashtable directly, so "reading" a tc action is reading from hashtable. Sorry if this wasn't clear.
OK, but with the current code there is no need to protect the hash table with an RCU semantics. The ref counting ensures the hash table entries are always available and any 'replace' commands on actions are handled internally in the action itself with rcu_assign_pointer replacing old params with new params. The fast path readers will always read a consistent set of parameters in this scheme. So no need for an rcu hash table. The reference count though should likely be atomic because not all increments/decrements are protected by RTNL lock. .John