From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 3976ECB24 for ; Thu, 16 Jun 2016 16:32:14 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 16 Jun 2016 07:32:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,480,1459839600"; d="scan'208";a="988815433" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.182]) by fmsmga001.fm.intel.com with SMTP; 16 Jun 2016 07:32:11 -0700 Received: by (sSMTP sendmail emulation); Thu, 16 Jun 2016 15:32:10 +0025 Date: Thu, 16 Jun 2016 15:32:10 +0100 From: Bruce Richardson To: "Iremonger, Bernard" Cc: "dev@dpdk.org" , "Doherty, Declan" , "Ananyev, Konstantin" Message-ID: <20160616143210.GB14984@bricha3-MOBL3> References: <1464280727-25752-2-git-send-email-bernard.iremonger@intel.com> <1465751489-10111-1-git-send-email-bernard.iremonger@intel.com> <1465751489-10111-4-git-send-email-bernard.iremonger@intel.com> <20160613091800.GA17996@bricha3-MOBL3> <8CEF83825BEC744B83065625E567D7C21A038B2E@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A038B2E@IRSMSX108.ger.corp.intel.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v3 3/4] bonding: take queue spinlock in rx/tx burst functions 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: Thu, 16 Jun 2016 14:32:14 -0000 On Mon, Jun 13, 2016 at 01:28:08PM +0100, Iremonger, Bernard wrote: > Hi Bruce, > > > > > Subject: Re: [dpdk-dev] [PATCH v3 3/4] bonding: take queue spinlock in rx/tx > > burst functions > > > > On Sun, Jun 12, 2016 at 06:11:28PM +0100, Bernard Iremonger wrote: > > > Use rte_spinlock_trylock() in the rx/tx burst functions to take the > > > queue spinlock. > > > > > > Signed-off-by: Bernard Iremonger > > > Acked-by: Konstantin Ananyev > > > --- > > > > Why does this particular PMD need spinlocks when doing RX and TX, while > > other device types do not? How is adding/removing devices from a bonded > > device different to other control operations that can be done on physical > > PMDs? Is this not similar to say bringing down or hotplugging out a physical > > port just before an RX or TX operation takes place? > > For all other PMDs we rely on the app to synchronise control and data plane > > operation - why not here? > > > > /Bruce > > This issue arose during VM live migration testing. > For VM live migration it is necessary (while traffic is running) to be able to remove a bonded slave device, stop it, close it and detach it. > It a slave device is removed from a bonded device while traffic is running a segmentation fault may occur in the rx/tx burst function. The spinlock has been added to prevent this occurring. > > The bonding device already uses a spinlock to synchronise between the add and remove functionality and the slave_link_status_change_monitor code. > > Previously testpmd did not allow, stop, close or detach of PMD while traffic was running. Testpmd has been modified with the following patchset > > http://dpdk.org/dev/patchwork/patch/13472/ > > It now allows stop, close and detach of a PMD provided in it is not forwarding and is not a slave of bonded PMD. > I will admit to not being fully convinced, but if nobody else has any serious objections, and since this patch has been reviewed and acked, I'm ok to merge it in. I'll do so shortly. /Bruce