From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id C0D3B952 for ; Wed, 15 Feb 2017 22:56:48 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2017 13:56:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,166,1484035200"; d="scan'208";a="934359706" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 15 Feb 2017 13:56:47 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 15 Feb 2017 13:56:47 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.230]) by FMSMSX110.amr.corp.intel.com ([169.254.14.203]) with mapi id 14.03.0248.002; Wed, 15 Feb 2017 13:56:46 -0800 From: "Wiles, Keith" To: Jan Blunck CC: Jerin Jacob , Shreyansh Jain , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 3/7] eal: move virtual device probing into a bus Thread-Index: AQHSh5fH4K3Z7eBhQkKQQ7+2ormWKKFq1/CAgAAMKwCAACDrgIAAHrKA Date: Wed, 15 Feb 2017 21:56:45 +0000 Message-ID: References: <1487152929-23627-1-git-send-email-jblunck@infradead.org> <1487152929-23627-4-git-send-email-jblunck@infradead.org> <485202cf-3644-5ee9-45b5-d443569bf5b5@nxp.com> <7843A545-14B6-4CD9-9689-ABD123B85890@intel.com> <20170215172530.GA8119@localhost.localdomain> <9AE1640E-5F5D-446F-A304-F94D6667FC02@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.102.97] Content-Type: text/plain; charset="us-ascii" Content-ID: <0EDA8E64D8514C40B00EA13A3DADFFE1@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 3/7] eal: move virtual device probing into a bus 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: Wed, 15 Feb 2017 21:56:49 -0000 > On Feb 15, 2017, at 2:06 PM, Jan Blunck wrote: >=20 > On Wed, Feb 15, 2017 at 7:09 PM, Wiles, Keith wro= te: >>=20 >> I guess I see this differently, meaning we modified the system to put vd= ev devices last only because we do not have clean way to startup the system= for pdev/vdev devices. The application should be agnostic to the devices b= eing started and the system needs to determine the correct order without a = chicken and egg problem. The test-pmd application just starts from 0 to n t= o initialize devices, which he should be able to do in any order. It is pos= sible the application could initialize the devices (pdev/vdev) in any order= , which the current design would break if they tried to init the bonding dr= iver first. >>=20 >=20 > Apart from the usability (vdevs always first) I wonder what kind of > usecase you are after. If I understand you correctly you want to: > - probe the virtual devices first > - start/configure the virtual devices last >=20 > ... and only in some cases. From what I understand this requires a > domain specific way to model dependencies between ports, e.g. some > standardized device arguments parsed by EAL, and combined with your > requirement to assign the lowest port numbers for the vdev devices > even a scheduler. I do not think moving vdev to the front is going to really solve my use cas= e it, as it will create more problems then solve. The real case here is if = the application developer inits devices out of order then he can hit the bo= nding driver bug. The current solution does not really fix the problem only= bandaid the problem for the common ordered case. Do we need to solve this problem, maybe not, but it needs to be documented = or we need to provide a cleaner way for the application to startup all devi= ces in the correct order. A possible way is to have callback to the applica= tion in the correct order for him to initialize the devices, but not a grea= t solution per say. >=20 > Maybe we could reduce complexity by doing some simple things instead: > if you present the ports in reverse order to the users the vdev come > first. Probably this even increases usability because the most recent > created port is the one that the user is anyway most interested in. >=20 >> What happens if a vdev needs to be initialized before a pdev device? >>=20 >=20 > This should never happen. The pdev devices offer a plain view on the > "system", which means no topology at all. The vdev devices are devices > that do not have a "system" representation, e.g. a library. I don't > think the EAL should offer an alternative API to system programming in > a way that you enumerate your PCI devices through a vdev that is > accessing hardware through another library. >=20 >> Not saying we need to solve this problem now, but need to figure this ou= t some how. Maybe we need a priority for pdev/vdev devices to determine ini= t order???? >>=20 Regards, Keith