From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id D9EC3AFCF for ; Wed, 25 Jun 2014 18:15:39 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 25 Jun 2014 09:10:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,546,1400050800"; d="scan'208";a="563305990" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga002.jf.intel.com with ESMTP; 25 Jun 2014 09:15:55 -0700 Received: from irsmsx153.ger.corp.intel.com (163.33.192.75) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 25 Jun 2014 17:15:54 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.31]) by IRSMSX153.ger.corp.intel.com ([169.254.9.233]) with mapi id 14.03.0123.003; Wed, 25 Jun 2014 17:15:54 +0100 From: "Richardson, Bruce" To: Thomas Monjalon , "Doherty, Declan" Thread-Topic: [dpdk-dev] [PATCH v7 3/6] EAL support for link bonding device initialization Thread-Index: AQHPkI7eouY/DzUgd0+/JelUIpf1AZuB/wjA Date: Wed, 25 Jun 2014 16:15:53 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B02CEE3C11@IRSMSX103.ger.corp.intel.com> References: <1403621531-30487-1-git-send-email-declan.doherty@intel.com> <6725316.vIZR3J0FYH@xps13> <345C63BAECC1AD42A2EC8C63AFFC3ADC272FB41C@IRSMSX101.ger.corp.intel.com> <2511187.jBxQWp3IxM@xps13> In-Reply-To: <2511187.jBxQWp3IxM@xps13> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v7 3/6] EAL support for link bonding device initialization 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: Wed, 25 Jun 2014 16:15:40 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Wednesday, June 25, 2014 9:01 AM > To: Doherty, Declan > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v7 3/6] EAL support for link bonding devic= e > initialization >=20 > 2014-06-25 14:41, Doherty, Declan: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > Not sure to understand why you need to split rte_eal_dev_init() in 2 > > > steps. > > > Should it be possible to keep existing rte_eal_dev_init() > > > behaviour and makes further initialization when calling > > > rte_eth_dev_configure()? > > > I've seen it's empty for bonding device: > > > > Hi Thomas, that need to split rte_eal_dev_init into 2 steps doesn't com= e > > explicitly from the bonded device itself, as a bonded device could be > > created at any time during initialization, the issue arises from the fa= ct > > that none of physical devices are allocated/initialized until after > > pci_probe_all_drivers() is called, this puts an explicit constraint on = when > > it is possible to create a bonded device which has physical devices as > > slaves, as the phyiscal devices don't exist at the initial call to > > rte_eal_dev_init() and therefore can't be added as slaves to the bonded > > device. > > It isn't possible to keep the rte_eal_dev_init() behavior and use > > rte_eth_dev_configure() to complete initialization without radically > > changing the behavior of the bonding library, and the current > > functionality of rte_eth_bond_slave_add(), as this would need to no lon= ger > > actually add a slave, but to save the name of a slave to be retrieved a= t > > some point in the future to be added as a slave to the bonded device. >=20 > I'm sure it would be much cleaner if you split rte_eth_bond_slave_add() > instead of splitting rte_eal_dev_init(). > If I understand well, you should first save kvargs for slaves and add the= m at > configure time. >=20 > Then you could remove PMD_BDEV type and use PMD_VDEV. >=20 > I know it's an additional work but API cleaning really deserves it. >=20 Or else we could just go back to the earlier versions of the submission and= accept the fact that some types of devices are designed to be used from co= de via an API and that we don't need to be able to set up every type of dev= ice via the application command-line. The code for this feature and rework = to EAL has just got continually more complicated every time due to the need= to continually workaround gotchas when trying to enable this for second-le= vel ethdevs. /Bruce