From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 748AF9A91 for ; Fri, 13 May 2016 19:19:07 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 13 May 2016 10:19:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,614,1455004800"; d="scan'208";a="702364650" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by FMSMGA003.fm.intel.com with ESMTP; 13 May 2016 10:18:36 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.130]) by IRSMSX103.ger.corp.intel.com ([169.254.3.54]) with mapi id 14.03.0248.002; Fri, 13 May 2016 18:18:35 +0100 From: "Ananyev, Konstantin" To: "Ananyev, Konstantin" , Stephen Hemminger , "Doherty, Declan" CC: "Iremonger, Bernard" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/5] bonding: replace spinlock with read/write lock Thread-Index: AQHRpvF5zY5KwBchMEiw1zqtXVzCN5+rpnuAgABaV4CACySCgIAAAhsw Date: Fri, 13 May 2016 17:18:35 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B5098C@irsmsx105.ger.corp.intel.com> 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> <20160506085539.1ece142c@xeon-e3> <2601191342CEEE43887BDE71AB97725836B50971@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836B50971@irsmsx105.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/5] bonding: replace spinlock with read/write lock X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 17:19:07 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin > Sent: Friday, May 13, 2016 6:11 PM > To: Stephen Hemminger; Doherty, Declan > Cc: Iremonger, Bernard; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/5] bonding: replace spinlock with read/w= rite lock >=20 >=20 >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > > Sent: Friday, May 06, 2016 4:56 PM > > To: Doherty, Declan > > Cc: Iremonger, Bernard; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 1/5] bonding: replace spinlock with read= /write lock > > > > On Fri, 6 May 2016 11:32:19 +0100 > > Declan Doherty wrote: > > > > > On 05/05/16 18:12, Stephen Hemminger wrote: > > > > On Thu, 5 May 2016 16:14:56 +0100 > > > > Bernard Iremonger wrote: > > > > > > > >> Fixes: a45b288ef21a ("bond: support link status polling") > > > >> Signed-off-by: Bernard Iremonger > > > > > > > > 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 devi= ce > > > being removed/closed during it's operation now that we support > > > hotplugging, in the worst case this could mean we have 2(rx+tx) * que= ues > > > 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 sma= ll, > > and it is actually faster to use spinlock for that. >=20 > I don't think that window we hold the lock is that small, let say if we h= ave > a burst of 32 packets * (let say) 50 cycles/pkt =3D ~1500 cycles - each I= O thread would stall. > For me that's long enough to justify rwlock usage here, especially that > DPDK rwlock price is not much bigger (as I remember) then spinlock - > it is basically 1 CAS operation. As another alternative we can have a spinlock per queue, then different IO = threads doing RX/XTX over different queues will be uncontended at all. Though control thread would need to grab locks for all configured queues :) Konstantin >=20 > Konstantin >=20