From: John Fastabend <john.fastabend@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
David Miller <davem@davemloft.net>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
Jamal Hadi Salim <jhs@mojatatu.com>,
Hadar Hen Zion <hadarh@mellanox.com>,
Amir Vadai <amirva@mellanox.com>
Subject: Re: [PATCH net] net_sched: act_mirred: full rcu conversion
Date: Mon, 12 Sep 2016 08:34:47 -0700 [thread overview]
Message-ID: <57D6CB17.6030007@gmail.com> (raw)
In-Reply-To: <CAM_iQpXycdn9_LW_qYzUe5T97ABOj3KrivjCB5ho9wbKeFR0MQ@mail.gmail.com>
On 16-09-11 11:12 PM, Cong Wang wrote:
> On Fri, Sep 9, 2016 at 8:52 AM, John Fastabend <john.fastabend@gmail.com> wrote:
>> On 16-09-08 10:26 PM, Cong Wang wrote:
>>> On Thu, Sep 8, 2016 at 8:51 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>> On Thu, 2016-09-08 at 08:47 -0700, John Fastabend wrote:
>>>>
>>>>> 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 <john.r.fastabend@intel.com>
>>>>>
>>>>
>>>> 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
next prev parent reply other threads:[~2016-09-12 15:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-02 5:57 [RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions Cong Wang
2016-09-02 5:57 ` [RFC Patch net-next 1/6] net_sched: use RCU for action hash table Cong Wang
2016-09-06 12:47 ` Jamal Hadi Salim
2016-09-06 22:37 ` Cong Wang
2016-09-02 5:57 ` [RFC Patch net-next 2/6] net_sched: introduce tcf_hash_replace() Cong Wang
2016-09-06 12:52 ` Jamal Hadi Salim
2016-09-06 22:34 ` Cong Wang
2016-09-02 5:57 ` [RFC Patch net-next 3/6] net_sched: return NULL in tcf_hash_check() Cong Wang
2016-09-02 5:57 ` [RFC Patch net-next 4/6] net_sched: introduce tcf_hash_copy() Cong Wang
2016-09-02 5:57 ` [RFC Patch net-next 5/6] net_sched: use rcu in fast path Cong Wang
2016-09-06 14:52 ` Eric Dumazet
2016-09-08 6:04 ` John Fastabend
2016-09-08 13:28 ` Eric Dumazet
2016-09-08 15:35 ` [PATCH net] net_sched: act_mirred: full rcu conversion Eric Dumazet
2016-09-08 15:47 ` John Fastabend
2016-09-08 15:51 ` Eric Dumazet
2016-09-09 5:26 ` Cong Wang
2016-09-09 12:23 ` Eric Dumazet
2016-09-09 15:52 ` John Fastabend
2016-09-12 6:12 ` Cong Wang
2016-09-12 15:34 ` John Fastabend [this message]
2016-09-09 5:24 ` Cong Wang
2016-09-09 5:48 ` Alexei Starovoitov
2016-09-09 5:59 ` Cong Wang
2016-09-09 12:25 ` Eric Dumazet
2016-09-09 12:23 ` Eric Dumazet
2016-09-12 5:46 ` Cong Wang
2016-09-08 15:49 ` [RFC Patch net-next 5/6] net_sched: use rcu in fast path John Fastabend
2016-09-09 5:54 ` Cong Wang
2016-09-09 15:25 ` John Fastabend
2016-09-09 5:49 ` Cong Wang
2016-09-02 5:57 ` [RFC Patch net-next 6/6] net_sched: switch to RCU API for act_mirred Cong Wang
2016-09-02 7:09 ` [RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions Jiri Pirko
2016-09-02 19:44 ` Cong Wang
2016-09-07 16:23 ` John Fastabend
2016-09-08 6:05 ` John Fastabend
2016-09-09 5:22 ` Cong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57D6CB17.6030007@gmail.com \
--to=john.fastabend@gmail.com \
--cc=amirva@mellanox.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hadarh@mellanox.com \
--cc=jhs@mojatatu.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).