From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 2C37D3B5 for ; Sat, 28 Jan 2017 14:11:40 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 28 Jan 2017 05:11:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,301,1477983600"; d="scan'208";a="1100097227" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga001.fm.intel.com with ESMTP; 28 Jan 2017 05:11:38 -0800 Date: Sat, 28 Jan 2017 21:14:03 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: "Ananyev, Konstantin" , "Yigit, Ferruh" , dev@dpdk.org, "Horton, Remy" Message-ID: <20170128131403.GA20916@yliu-dev.sh.intel.com> References: <4d897cf9-f1f4-d924-10cd-63e95b12b411@intel.com> <20170123125256.GH10293@yliu-dev.sh.intel.com> <2601191342CEEE43887BDE71AB9772583F10A841@irsmsx105.ger.corp.intel.com> <2493743.8AWo4SqSMn@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2493743.8AWo4SqSMn@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH] ethdev: fix wrong memset X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 13:11:41 -0000 On Wed, Jan 25, 2017 at 12:16:58PM +0100, Thomas Monjalon wrote: > > As I understand, the main problem is that rte_eth_devices[] is local, > > while rte_eth_dev_data points to the shared memory array. > > And rte_eth_dev_allocate() assumes that if rte_eth_devices[x] is free, > > then rte_eth_dev_data[port_id] is also free. > > Which is wrong in case when primary/secondary processes have different devices attached. > > Another problem is that inside rte_ethdev.c we manipulate rte_eth_dev_data[] > > contents without grabbing any lock. > > Yes there are a lot of problems with the multiproc mode because it has > been implemented as a hack. Oh, right, "hacky" is the word I intended to say in my last email. > We are fixing some cases without figuring the whole picture. Agreed. > > I'll apply the patch from Remy which fixes a case where process creates I would ask you not to apply that. IMO, his patch may have "fixed" a crash he saw, but it doesn't looks like to me it really fixes anything: the driver may reference rte_eth_data belongs to another driver -- things can't be right afterwards. > vdev (local data) and, hopefully, primary does no hotplug of PCI dev. > > I'll restart this discussion with a bigger picture of what multiproc is, > and what are the issues. Great! And I'm keen to know how the multiproc is actually used in real life (and why they don't use multiple thread). Most importantly, does people really care about it? (I fixed few virtio multiproc issues that I know there are some people/companies using it, and I want to know if there are more). OTOH, an initial idea comes to my mind now is, make the port_id a global id among primary and secondary process: - same device will get same port id (my patch acertains that) - different device will get different port id --yliu