From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <keith.wiles@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id C0D3B952
 for <dev@dpdk.org>; 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" <keith.wiles@intel.com>
To: Jan Blunck <jblunck@infradead.org>
CC: Jerin Jacob <jerin.jacob@caviumnetworks.com>, Shreyansh Jain
 <shreyansh.jain@nxp.com>, "dev@dpdk.org" <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: <A5639D7A-3964-4437-8B92-457238DEB00A@intel.com>
References: <1487152929-23627-1-git-send-email-jblunck@infradead.org>
 <1487152929-23627-4-git-send-email-jblunck@infradead.org>
 <bfb6d89d-5043-c92d-8894-5d92b6e7d74d@nxp.com>
 <485202cf-3644-5ee9-45b5-d443569bf5b5@nxp.com>
 <7843A545-14B6-4CD9-9689-ABD123B85890@intel.com>
 <DB5PR0401MB20540174CD3402FF8B0782AE905B0@DB5PR0401MB2054.eurprd04.prod.outlook.com>
 <20170215172530.GA8119@localhost.localdomain>
 <9AE1640E-5F5D-446F-A304-F94D6667FC02@intel.com>
 <CALe+Z02oSPoFFWz8bhfWrXroJ8xbnyKTSxy4Jfy+wuVM3s0yCw@mail.gmail.com>
In-Reply-To: <CALe+Z02oSPoFFWz8bhfWrXroJ8xbnyKTSxy4Jfy+wuVM3s0yCw@mail.gmail.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 21:56:49 -0000


> On Feb 15, 2017, at 2:06 PM, Jan Blunck <jblunck@infradead.org> wrote:
>=20
> On Wed, Feb 15, 2017 at 7:09 PM, Wiles, Keith <keith.wiles@intel.com> 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