[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <VI1PR0501MB21435FFC6DA3D72DF79C1E26AB470@VI1PR0501MB2143.eurprd05.prod.outlook.com>
Date: Tue, 24 Oct 2017 06:17:14 +0000
From: Chris Mi <chrism@...lanox.com>
To: Cong Wang <xiyou.wangcong@...il.com>
CC: Jamal Hadi Salim <jhs@...atatu.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
Lucas Bates <lucasb@...atatu.com>,
Jiri Pirko <jiri@...nulli.us>,
David Miller <davem@...emloft.net>
Subject: RE: [patch net v2 1/4] net/sched: Change tc_action refcnt and bindcnt
to atomic
> -----Original Message-----
> From: Cong Wang [mailto:xiyou.wangcong@...il.com]
> Sent: Monday, October 23, 2017 11:40 PM
> To: Chris Mi <chrism@...lanox.com>
> Cc: Jamal Hadi Salim <jhs@...atatu.com>; Linux Kernel Network Developers
> <netdev@...r.kernel.org>; Lucas Bates <lucasb@...atatu.com>; Jiri Pirko
> <jiri@...nulli.us>; David Miller <davem@...emloft.net>
> Subject: Re: [patch net v2 1/4] net/sched: Change tc_action refcnt and
> bindcnt to atomic
>
> On Sun, Oct 22, 2017 at 7:47 PM, Chris Mi <chrism@...lanox.com> wrote:
> >
> > It seems it is not easy to discard call_rcu(). I'm afraid even if we
> > have a final solution without call_rcu(), it is not mature at the
> > beginning as well. I mean we also need time
>
> Why do you believe it is not easy? RTNL lock is already there,
> list_splice_init_rcu() is there too. I can naturally divide my patches for each
> module so that they are much easier to backport than yours.
I tested your patches. It takes about 17 seconds to run the same test.
I believe your code is simpler and easy to maintain. If it is stable,
we will also get benefit. Thanks!
>
>
> > to fix the possible bugs of the new design. And maybe to destroy the
> > filters in parallel is the right direction. If this bug is the last
> > bug brought by call_rcu(), then changing it may not be a good idea.
>
> Again, you have to prove this is the last bug, I seriously doubt it is.
>
>
> >
> > Patch 1 is straightforward to use atomic. Patch 2 is to convert the list to
> array.
>
> Both are big in size.
>
>
> > I think there is no harm to the new design. Patch 3 and 4 are useful test
> case.
>
> It definitely doesn't harm, but why do we waste time on it when we know
> there is a better way? It is clearly not easy for backport either, in fact it is
> harder w.r.t. size.
>
>
> > We also need it with new design to make sure there is no regression.
> >
>
> Are you saying I can't trust your test cases? ;)
>
>
> > So I think my patch set should not be held so long time.
>
> I think your patches should be dropped except the last two, I will take the
> last two for you.
>
> Thanks!
Powered by blists - more mailing lists