From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [PATCH 3/7] eal: move virtual device probing into a bus 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Jerin Jacob , Shreyansh Jain , "dev@dpdk.org" To: Jan Blunck 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) In-Reply-To: Content-Language: en-US Content-ID: <0EDA8E64D8514C40B00EA13A3DADFFE1@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > 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