From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <huawei.xie@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by dpdk.org (Postfix) with ESMTP id 3DA049AA4
for <dev@dpdk.org>; Tue, 1 Mar 2016 09:39:37 +0100 (CET)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
by orsmga102.jf.intel.com with ESMTP; 01 Mar 2016 00:39:36 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,522,1449561600"; d="scan'208";a="924114178"
Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205])
by orsmga002.jf.intel.com with ESMTP; 01 Mar 2016 00:39:29 -0800
Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by
fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Tue, 1 Mar 2016 00:39:28 -0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Tue, 1 Mar 2016 00:39:28 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.136]) by
SHSMSX151.ccr.corp.intel.com ([169.254.3.18]) with mapi id 14.03.0248.002;
Tue, 1 Mar 2016 16:39:26 +0800
From: "Xie, Huawei" <huawei.xie@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Thread-Topic: [PATCH v4 4/4] virtio: return 1 to tell the upper layer we
don't take over this device
Thread-Index: AdFzj4MuUDrymegJT1SI/9bUpaqDKw==
Date: Tue, 1 Mar 2016 08:39:25 +0000
Message-ID: <C37D651A908B024F974696C65296B57B4C61B194@SHSMSX101.ccr.corp.intel.com>
References: <20151222035041.GA7532@pxdev.xzpeter.org>
<1870056.1ZGr9B153f@xps13>
<C37D651A908B024F974696C65296B57B4C61AD14@SHSMSX101.ccr.corp.intel.com>
<8208032.DLqNqWtROc@xps13>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Troitsky,
Nikita" <nikita.troitsky@intel.com>
Subject: Re: [dpdk-dev] [PATCH v4 4/4] virtio: return 1 to tell the upper
layer we don't take over this device
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <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: Tue, 01 Mar 2016 08:39:37 -0000
On 3/1/2016 4:24 PM, Thomas Monjalon wrote:=0A=
> 2016-03-01 07:53, Xie, Huawei:=0A=
>> On 3/1/2016 3:18 PM, Thomas Monjalon wrote:=0A=
>>> 2016-02-26 09:53, Huawei Xie:=0A=
>>>> @@ -1037,8 +1039,11 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev=
)=0A=
>>>> =0A=
>>>> pci_dev =3D eth_dev->pci_dev;=0A=
>>>> =0A=
>>>> - if (vtpci_init(pci_dev, hw) < 0)=0A=
>>>> - return -1;=0A=
>>>> + ret =3D vtpci_init(pci_dev, hw);=0A=
>>>> + if (ret) {=0A=
>>>> + rte_free(eth_dev->data->mac_addrs);=0A=
>>> The freeing seems not related to this patch.=0A=
>> I can send a separate patch, ok within this patchset?=0A=
> Yes=0A=
>=0A=
>>> [...]=0A=
>>>> PMD_INIT_LOG(INFO, "trying with legacy virtio pci.");=0A=
>>>> - if (legacy_virtio_resource_init(dev, hw) < 0)=0A=
>>>> + if (legacy_virtio_resource_init(dev, hw) < 0) {=0A=
>>>> + if (dev->kdrv =3D=3D RTE_KDRV_UNKNOWN) {=0A=
>>>> + PMD_INIT_LOG(INFO,=0A=
>>>> + "skip kernel managed virtio device.");=0A=
>>>> + return 1;=0A=
>>>> + }=0A=
>>>> return -1;=0A=
>>>> + }=0A=
>>> You cannot skip a device if it was whitelisted.=0A=
>>> I think you should check RTE_DEVTYPE_WHITELISTED_PCI and throw an error=
=0A=
>>> in this case.=0A=
>> I feel there is a subtle difference on the understanding of -w args. To=
=0A=
>> me, without it, probe all devices; with it, only probe whiltelisted API.=
=0A=
>> That is all.=0A=
> I don't know if it is clearly documented indeed.=0A=
>=0A=
>> Do you mean that -w implies that devices whitelisted must be probed=0A=
>> successfully otherwise we throw an error? If i get it right, then what=
=0A=
>> about the devices whitelisted but without PMD driver?=0A=
> Yes we should probably consider the whitelist as a "forced" init.=0A=
> Later, we could introduce some device flags for probing/discovery:=0A=
> PROBE_AUTO, PROBE_FORCE, PROBE_IGNORE. It would make white/black list=0A=
> more precise.=0A=
>=0A=
>> I will fix, :).=0A=
>> if (dev->kdrv =3D=3D RTE_KDRV_UNKNOWN && dev->devargs->type !=3D=0A=
>> RTE_DEVTYPE_WHITELISTED_PCI) {=0A=
>> ....=0A=
>> return 1;=0A=
>> }=0A=
> You should also consider the blacklist case: if there is a blacklist,=0A=
> the not blacklisted devices must be initialised or throw an error.=0A=
>=0A=
Don't we already skip probing the blacklisted device in=0A=
rte_eal_pci_probe_one_driver?=0A=
=0A=