From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Igor Ryzhov <iryzhov@nfware.com>
Cc: dev@dpdk.org, David Marchand <david.marchand@6wind.com>,
"Liu, Yuanhan" <yuanhan.liu@intel.com>
Subject: Re: [dpdk-dev] rte_eth_dev_attach returns 0, although device is not attached
Date: Thu, 4 Aug 2016 16:47:25 +0100 [thread overview]
Message-ID: <57A3638D.2060300@intel.com> (raw)
In-Reply-To: <9C1AE4BF-9530-4596-BCF6-09E9AF7E55F3@nfware.com>
On 8/4/2016 3:54 PM, Igor Ryzhov wrote:
>
>> 4 авг. 2016 г., в 16:21, Ferruh Yigit <ferruh.yigit@intel.com
>> <mailto:ferruh.yigit@intel.com>> написал(а):
>>
>> On 8/4/2016 12:51 PM, Igor Ryzhov wrote:
>>> Hello Ferruh,
>>>
>>>> 4 авг. 2016 г., в 14:33, Ferruh Yigit <ferruh.yigit@intel.com
>>>> <mailto:ferruh.yigit@intel.com>> написал(а):
>>>>
>>>> Hi Igor,
>>>>
>>>> On 8/3/2016 5:58 PM, Igor Ryzhov wrote:
>>>>> Hello.
>>>>>
>>>>> Function rte_eth_dev_attach can return false positive result.
>>>>> It happens because rte_eal_pci_probe_one returns zero if no driver
>>>>> is found for the device:
>>>>> ret = pci_probe_all_drivers(dev);
>>>>> if (ret < 0)
>>>>> goto err_return;
>>>>> return 0;
>>>>> (pci_probe_all_drivers returns 1 in that case)
>>>>>
>>>>> For example, it can be easily reproduced by trying to attach virtio
>>>>> device, managed by kernel driver.
>>>>
>>>> You are right, and I did able to reproduce this issue with virtio as you
>>>> suggest.
>>>>
>>>> But I wonder why rte_eth_dev_get_port_by_addr() is not catching this.
>>>> Perhaps a dev->attached check needs to be added into this function.
>>
>> With a second check, rte_eth_dev_get_port_by_addr() catches it if the
>> driver is missing.
>>
>> But for virtio case, problem is not missing driver.
>> Problem is eth_virtio_dev_init() is returning a positive value on fail.
>>
>> Call stack is:
>> rte_eal_pci_probe_one
>> pci_probe_all_drivers
>> rte_eal_pci_probe_one_driver
>> rte_eth_dev_init
>> eth_virtio_dev_init
>>
>> So rte_eal_pci_probe_one_driver() also returns positive value, as no
>> driver found, and rte_eth_dev_get_port_by_addr() returns a valid
>> port_id, since rte_eth_dev_init() allocated an eth_dev.
>>
>> Briefly, this can be fixed in virtio pmd, instead of eal pci.
>>
>>>>
>>>>>
>>>>> I think it should be:
>>>>> ret = pci_probe_all_drivers(dev);
>>>>> if (ret)
>>>>> goto err_return;
>>>>> return 0;
>>>>
>>>> Your proposal looks good to me. Will you send a patch?
>>>
>>
>> Original code silently ignores the if driver is missing for that dev,
>> although it is still questionable, I think we can keep this as it is.
>>
>>> Patch sent.
>>
>> Sorry for this, but can you please test with following modification in
>> virtio:
>> index 07d6449..c74eeee 100644
>> --- a/drivers/net/virtio/virtio_ethdev.c
>> +++ b/drivers/net/virtio/virtio_ethdev.c
>> @@ -1156,7 +1156,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
>> if (pci_dev) {
>> ret = vtpci_init(pci_dev, hw, &dev_flags);
>> if (ret)
>> - return ret;
>> + return -1;
>> }
>>
>> /* Reset the device although not necessary at startup */
>
> I think it's not a good change, because it will break the idea of this
> patch - http://dpdk.org/browse/dpdk/commit/?id=ac5e1d83
Yes, breaks this one, I wasn't aware of this patch. But in this patch,
commit log says: "return 1 to tell the upper layer we
don't take over this device.", I am not sure upper layer designed for this.
>
> Also, with your patch the application will not start, because
> rte_eal_pci_probe will fail:
>
> if (ret < 0)
> rte_exit(EXIT_FAILURE, "Requested device " PCI_PRI_FMT
> " cannot be used\n", dev->addr.domain, dev->addr.bus,
> dev->addr.devid, dev->addr.function);
Yes it fails, and this looks like intended behavior. This failure is
correct according code.
>
> And now I think that maybe we should change the way rte_eal_pci_probe works.
> I think we shouldn't stop the application if just one of PCI devices is
> not probed successfully.
Agreed. Overall rte_exit() usage already discussed a few times.
I think best option is:
- don't exit app if rte_eal_pci_probe() fails, only print an error.
- eth_virtio_dev_init() return negative error value for all error cases
(including device managed by kernel)
Or perhaps RTE_KDRV_UNKNOWN check can be moved from virtio_pmd into
higher level and can be done for all devices. Like
pci_probe_one_driver() can fail if device driver is RTE_KDRV_UNKNOWN.
Any comments?
>
>>
>>
>>>
>>>>
>>>>> Best regards,
>>>>> Igor
>
next prev parent reply other threads:[~2016-08-04 15:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 16:58 Igor Ryzhov
2016-08-04 11:33 ` Ferruh Yigit
2016-08-04 11:51 ` Igor Ryzhov
2016-08-04 13:21 ` Ferruh Yigit
2016-08-04 14:54 ` Igor Ryzhov
2016-08-04 15:47 ` Ferruh Yigit [this message]
2016-08-05 12:29 ` Bruce Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57A3638D.2060300@intel.com \
--to=ferruh.yigit@intel.com \
--cc=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=iryzhov@nfware.com \
--cc=yuanhan.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).