From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net] net_sched: act_mirred: full rcu conversion Date: Fri, 09 Sep 2016 05:23:57 -0700 Message-ID: <1473423837.18970.46.camel@edumazet-glaptop3.roam.corp.google.com> References: <1472795840-31901-1-git-send-email-xiyou.wangcong@gmail.com> <1472795840-31901-6-git-send-email-xiyou.wangcong@gmail.com> <1473173528.10725.14.camel@edumazet-glaptop3.roam.corp.google.com> <57D0FF87.604@gmail.com> <1473341283.15733.33.camel@edumazet-glaptop3.roam.corp.google.com> <1473348943.15733.57.camel@edumazet-glaptop3.roam.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: David Miller , Linux Kernel Network Developers , Jamal Hadi Salim , John Fastabend , Hadar Hen Zion , Amir Vadai To: Cong Wang Return-path: Received: from mail-pa0-f65.google.com ([209.85.220.65]:33521 "EHLO mail-pa0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753113AbcIIMX7 (ORCPT ); Fri, 9 Sep 2016 08:23:59 -0400 Received: by mail-pa0-f65.google.com with SMTP id h5so3822752pao.0 for ; Fri, 09 Sep 2016 05:23:59 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 2016-09-08 at 22:24 -0700, Cong Wang wrote: > On Thu, Sep 8, 2016 at 8:35 AM, Eric Dumazet wrote: > > From: Eric Dumazet > > > > As reported by Cong Wang, I was lazy when I did initial RCU conversion > > of tc_mirred, as I thought I could avoid allocation/freeing of a > > parameter block. > > Quote from Eric Dumazet: > > https://www.mail-archive.com/netdev@vger.kernel.org/msg115482.html > > > Well, I added a READ_ONCE() to read tcf_action once. > > Adding rcu here would mean adding a pointer and extra cache line, to > deref the values. > > IMHO the race here has no effect . You either read the old or new value. > > > Me with facepalm... ;-) Point is still valid. Show me a real case where it was a serious problem, instead of simply theoretical. tc_mirred + ifb patches allowed us to reach a milestone, removing the last contended spinlocks, and you are catching up with this one year later. I wont backport this fix in Google prod kernels, because there is absolutely no way we need it, and the extra memory cache line might hurt latencies. Since you did not write a fix on your side since June 17th, I presume you do not care that much.