From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <keith.wiles@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
by dpdk.org (Postfix) with ESMTP id 5C2CEA2F
for <dev@dpdk.org>; Wed, 15 Feb 2017 15:22:36 +0100 (CET)
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
15 Feb 2017 06:22:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.35,166,1484035200"; d="scan'208";a="65477560"
Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202])
by fmsmga005.fm.intel.com with ESMTP; 15 Feb 2017 06:22:36 -0800
Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.230]) by
fmsmsx104.amr.corp.intel.com ([169.254.3.29]) with mapi id 14.03.0248.002;
Wed, 15 Feb 2017 06:22:36 -0800
From: "Wiles, Keith" <keith.wiles@intel.com>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
CC: Jan Blunck <jblunck@infradead.org>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH 3/7] eal: move virtual device probing into a
bus
Thread-Index: AQHSh5bzeexcaHy4BUqX1zetqW8FOg==
Date: Wed, 15 Feb 2017 14:22:34 +0000
Message-ID: <7843A545-14B6-4CD9-9689-ABD123B85890@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>
In-Reply-To: <485202cf-3644-5ee9-45b5-d443569bf5b5@nxp.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: <97CC329402125E4BB4DF3C37F0115FA6@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 14:22:37 -0000
> On Feb 15, 2017, at 8:15 AM, Shreyansh Jain <shreyansh.jain@nxp.com> wrot=
e:
>=20
> On Wednesday 15 February 2017 07:41 PM, Shreyansh Jain wrote:
>> On Wednesday 15 February 2017 03:32 PM, Jan Blunck wrote:
>>> This is a refactoring of the virtual device probing which moves into in=
to
>>> a proper bus structure.
>>>=20
>>> Signed-off-by: Jan Blunck <jblunck@infradead.org>
>>> ---
>>> lib/librte_eal/common/eal_common_dev.c | 22 -----------------
>>> lib/librte_eal/common/eal_common_vdev.c | 44
>>> +++++++++++++++++++++++++++++++++
>>> 2 files changed, 44 insertions(+), 22 deletions(-)
>>>=20
>>=20
>> [...]
>>=20
>>>=20
>>> diff --git a/lib/librte_eal/common/eal_common_vdev.c
>>> b/lib/librte_eal/common/eal_common_vdev.c
>>> index 7d6e54f..523a3d6 100644
>>> --- a/lib/librte_eal/common/eal_common_vdev.c
>>> +++ b/lib/librte_eal/common/eal_common_vdev.c
>>> @@ -37,8 +37,10 @@
>>> #include <stdint.h>
>>> #include <sys/queue.h>
>>>=20
>> [...]
>>=20
>>> +
>>> +static struct rte_bus rte_vdev_bus =3D {
>>> + .scan =3D vdev_scan,
>>> + .probe =3D vdev_probe,
>>> +};
>>> +
>>> +RTE_REGISTER_BUS_LATE(virtual, rte_vdev_bus);
>>>=20
>>=20
>> Does it matter if VDEV buses are registered before or after other
>> buses? Either way, the callbacks would be called in the order specified
>> in EAL.
>>=20
>>=20
>=20
> Just ignore this comment - I am misunderstood something.
>=20
> But another question: Is there specific reason VDEV should be registered/=
scanned *after* other devices? Is there some specific problem if we do othe=
rwise? (I think this is should be done, but I don't have a specific reason)=
.
Does the bonding driver which uses physical devices need to be registered a=
fter physical ones? In Pktgen I noticed the vdev after the physical ports a=
nd I could not blacklist them as the bonding driver needed them, which caus=
ed the bonding ports to have a greater port number. In the case of pktgen t=
he bonding ports were up around 8 or 10 and caused the display to not show =
the bonding ports. This is really just a usability problem for the develope=
r using Pktgen. I would like to see the vdev devices first, but as long as =
the drivers (like bonding) are fine with them being first.
Regards,
Keith