Re: [RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions

2016-09-08 Thread Cong Wang
On Wed, Sep 7, 2016 at 9:23 AM, John Fastabend wrote: > > hmm I'm trying to see where the questionable part is in the current > code? What is it exactly. All you need is a google search in netdev: https://www.mail-archive.com/netdev@vger.kernel.org/msg115480.html

Re: [RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions

2016-09-08 Thread John Fastabend
On 16-09-07 09:23 AM, John Fastabend wrote: > On 16-09-01 10:57 PM, Cong Wang wrote: >> Currently there are only two tc actions lockless: >> gact and mirred. But they are questionable because >> we don't have anything to prevent a parallel update >> on an existing tc action in hash table while

Re: [RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions

2016-09-07 Thread John Fastabend
On 16-09-01 10:57 PM, Cong Wang wrote: > Currently there are only two tc actions lockless: > gact and mirred. But they are questionable because > we don't have anything to prevent a parallel update > on an existing tc action in hash table while reading > it on fast path, this could be a problem

Re: [RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions

2016-09-02 Thread Cong Wang
On Fri, Sep 2, 2016 at 12:09 AM, Jiri Pirko wrote: > > I wonder, do you happen to have a very tiny narrow screen? LOL, yeah, I should fix the indentation... ;)

Re: [RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions

2016-09-02 Thread Jiri Pirko
Fri, Sep 02, 2016 at 07:57:14AM CEST, xiyou.wangc...@gmail.com wrote: >Currently there are only two tc actions lockless: >gact and mirred. But they are questionable because >we don't have anything to prevent a parallel update >on an existing tc action in hash table while reading >it on fast path,

[RFC Patch net-next 0/6] net_sched: really switch to RCU for tc actions

2016-09-01 Thread Cong Wang
Currently there are only two tc actions lockless: gact and mirred. But they are questionable because we don't have anything to prevent a parallel update on an existing tc action in hash table while reading it on fast path, this could be a problem when a tc action becomes complex. This patchset