From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH 1/5] bonding: replace spinlock with
 read/write lock
Date: Fri, 6 May 2016 08:55:39 -0700
Message-ID: <20160506085539.1ece142c@xeon-e3>
References: <1462461300-9962-1-git-send-email-bernard.iremonger@intel.com>
 <1462461300-9962-2-git-send-email-bernard.iremonger@intel.com>
 <20160505101233.191151ac@xeon-e3>
 <7f47b47d-945a-c265-4db3-dc0d6850a348@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Bernard Iremonger <bernard.iremonger@intel.com>, dev@dpdk.org
To: Declan Doherty <declan.doherty@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com
 [209.85.192.180]) by dpdk.org (Postfix) with ESMTP id D5620388F
 for <dev@dpdk.org>; Fri,  6 May 2016 17:55:27 +0200 (CEST)
Received: by mail-pf0-f180.google.com with SMTP id 77so50988193pfv.2
 for <dev@dpdk.org>; Fri, 06 May 2016 08:55:27 -0700 (PDT)
In-Reply-To: <7f47b47d-945a-c265-4db3-dc0d6850a348@intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, 6 May 2016 11:32:19 +0100
Declan Doherty <declan.doherty@intel.com> wrote:

> On 05/05/16 18:12, Stephen Hemminger wrote:
> > On Thu,  5 May 2016 16:14:56 +0100
> > Bernard Iremonger <bernard.iremonger@intel.com> wrote:
> >
> >> Fixes: a45b288ef21a ("bond: support link status polling")
> >> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> >
> > You know an uncontested reader/writer lock is significantly slower
> > than a spinlock.
> >
> 
> As we can have multiple readers of the active slave list / primary 
> slave, basically any tx/rx burst call needs to protect against a device 
> being removed/closed during it's operation now that we support 
> hotplugging, in the worst case this could mean we have 2(rx+tx) * queues 
> possibly using the active slave list simultaneously, in that case I 
> would have thought that a spinlock would have a much more significant 
> affect on performance?

Right, but the window where the shared variable is accessed is very small,
and it is actually faster to use spinlock for that.