From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id BCF221C52; Tue, 25 Oct 2016 15:59:56 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP; 25 Oct 2016 06:59:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,545,1473145200"; d="scan'208";a="1058849875" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.210.150]) by fmsmga001.fm.intel.com with SMTP; 25 Oct 2016 06:59:54 -0700 Received: by (sSMTP sendmail emulation); Tue, 25 Oct 2016 14:59:52 +0100 Date: Tue, 25 Oct 2016 14:59:52 +0100 From: Bruce Richardson To: Declan Doherty Cc: Ilya Maximets , dev@dpdk.org, Heetae Ahn , Yuanhan Liu , Eric Kinzie , Bernard Iremonger , stable@dpdk.org Message-ID: <20161025135952.GA10444@bricha3-MOBL3.ger.corp.intel.com> References: <1473251290-22053-1-git-send-email-i.maximets@samsung.com> <20161019095525.GK27816@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161019095525.GK27816@bricha3-MOBL3.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.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [PATCH] Revert "bonding: use existing enslaved device queues" 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: Tue, 25 Oct 2016 13:59:57 -0000 On Wed, Oct 19, 2016 at 10:55:25AM +0100, Bruce Richardson wrote: > On Thu, Oct 06, 2016 at 03:32:36PM +0100, Declan Doherty wrote: > > On 07/09/16 13:28, Ilya Maximets wrote: > > > This reverts commit 5b7bb2bda5519b7800f814df64d4e015282140e5. > > > > > > It is necessary to reconfigure all queues every time because configuration > > > can be changed. > > > > > > > Hey Ilya, this makes sense. I guess this was my original intention but I > > missed this case in my review of the change. > > > > > For example, if we're reconfiguring bonding device with new memory pool, > > > already configured queues will still use the old one. And if the old > > > mempool be freed, application likely will panic in attempt to use > > > freed mempool. > > > > > > This happens when we use the bonding device with OVS 2.6 while MTU > > > reconfiguration: > > > > > > PANIC in rte_mempool_get_ops(): > > > assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed > > > > > > Cc: > > > Signed-off-by: Ilya Maximets > > > --- > > > > Acked-by: Declan Doherty > > Applied to dpdk-next-net/rel_16_11 > Patch taken out of branch due to on-going discussion in this thread. It can be re-applied later if consensus is reached that it is ok. Apologies for any confusion caused by this, but after discussion with the driver maintainer, we feel this is the safest course for now. /Bruce