All of lore.kernel.org
 help / color / mirror / Atom feed
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: 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
> 

  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 rte_eth_dev_attach returns 0, although device is not attached 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.