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
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
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
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... ;)
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,
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