Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751424AbdCSBaW (ORCPT ); Sat, 18 Mar 2017 21:30:22 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:34580 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751359AbdCSBaU (ORCPT ); Sat, 18 Mar 2017 21:30:20 -0400 Date: Sat, 18 Mar 2017 18:21:21 -0700 (PDT) Message-Id: <20170318.182121.439615057765380575.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: eric.dumazet@gmail.com, elena.reshetova@intel.com, keescook@chromium.org, peterz@infradead.org, netdev@vger.kernel.org, bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org, kuznet@ms2.inr.ac.ru, jmorris@namei.org, kaber@trash.net, stephen@networkplumber.org, ishkamiel@gmail.com, dwindsor@gmail.com, akpm@linux-foundation.org Subject: Re: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t From: David Miller In-Reply-To: <20170318164759.GA23837@gondor.apana.org.au> References: <1489767196.28631.305.camel@edumazet-glaptop3.roam.corp.google.com> <20170318164759.GA23837@gondor.apana.org.au> X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Sat, 18 Mar 2017 18:21:25 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 831 Lines: 21 From: Herbert Xu Date: Sun, 19 Mar 2017 00:47:59 +0800 > Eric Dumazet wrote: >> On Fri, 2017-03-17 at 07:42 +0000, Reshetova, Elena wrote: >> >>> Should we then first measure the actual numbers to understand what we >>> are talking here about? >>> I would be glad to do it if you suggest what is the correct way to do >>> measurements here to actually reflect the real life use cases. >> >> How have these patches been tested in real life exactly ? >> >> Can you quantify number of added cycles per TCP packet, where I expect >> we have maybe 20 atomic operations in all layers ... > > I completely agree. I think this thing needs to default to the > existing atomic_t behaviour. I totally agree as well, the refcount_t facility as-is is unacceptable for networking.