From: "lihuisong (C)" <lihuisong@huawei.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: <dev@dpdk.org>, <stephen@networkplumber.org>,
<ferruh.yigit@amd.com>,
"Ajit Khaparde" <ajit.khaparde@broadcom.com>,
Somnath Kotur <somnath.kotur@broadcom.com>,
Praveen Shetty <praveen.shetty@intel.com>,
Andrew Boyer <andrew.boyer@amd.com>,
Dariusz Sosnowski <dsosnowski@nvidia.com>,
Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
"Bing Zhao" <bingz@nvidia.com>, Ori Kam <orika@nvidia.com>,
Suanming Mou <suanmingm@nvidia.com>,
Matan Azrad <matan@nvidia.com>,
Chaoyong He <chaoyong.he@corigine.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
<fengchengwen@huawei.com>
Subject: Re: [PATCH v1 2/2] ethdev: fix skip valid port in probing callback
Date: Mon, 13 Jan 2025 17:35:02 +0800 [thread overview]
Message-ID: <0293d4d1-0df7-63e1-3dba-244729a78bb0@huawei.com> (raw)
In-Reply-To: <1988729.PYKUYFuaPT@thomas>
Hi Thomas,
在 2025/1/13 16:16, Thomas Monjalon 写道:
> 13/01/2025 03:55, Huisong Li:
>> The event callback in application may use the macro RTE_ETH_FOREACH_DEV to
>> iterate over all enabled ports to do something(like, verifying the port id
>> validity) when receive a probing event. If the ethdev state of a port is
>> not RTE_ETH_DEV_UNUSED, this port will be considered as a valid port.
>>
>> However, this state is set to RTE_ETH_DEV_ATTACHED after pushing probing
>> event. It means that probing callback will skip this port. But this
>> assignment can not move to front of probing notification. See
>> commit be8cd210379a ("ethdev: fix port probing notification")
>>
>> So this patch has to add a new state, RTE_ETH_DEV_ALLOCATED. Set the ethdev
>> state to RTE_ETH_DEV_ALLOCATED before pushing probing event and set it to
>> RTE_ETH_DEV_ATTACHED after definitely probed. And this port is valid if its
>> device state is 'ALLOCATED' or 'ATTACHED'.
> If you do that, changing the definition of eth_dev_find_free_port()
> you allow the application using a port before probing is finished.
Yes, it's not reasonable.
Thinking your comment twice, I feel that the root cause of this issue is
application want to check if the port id is valid.
However, application just receive the new event from the device and the
port id of this device must be valid when report new event.
So application can think the received new event is valid and don't need
to check, right?
If so I think this series can be dropped.
> It is the same as changing the state to RTE_ETH_DEV_ATTACHED
> before calling the event callback.
>
> So this is a NACK.
>
> Why do you need drivers to check the state of a notified device?
> If it is RTE_ETH_EVENT_NEW, you know that's a new device,
> there is nothing else to check.
It just modified the verification about RTE_ETH_DEV_UNUSED in the device
driver.
Driver not need to know the event.
>
>
> .
next prev parent reply other threads:[~2025-01-13 9:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-13 2:55 [PATCH v1 0/2] " Huisong Li
2025-01-13 2:55 ` [PATCH v1 1/2] app/testpmd: check the validity of the port Huisong Li
2025-01-13 2:55 ` [PATCH v1 2/2] ethdev: fix skip valid port in probing callback Huisong Li
2025-01-13 8:16 ` Thomas Monjalon
2025-01-13 9:35 ` lihuisong (C) [this message]
2025-01-13 10:57 ` Thomas Monjalon
2025-01-13 11:23 ` lihuisong (C)
2025-01-13 12:05 ` lihuisong (C)
2025-01-13 12:30 ` Thomas Monjalon
2025-01-13 12:47 ` lihuisong (C)
2025-01-13 13:14 ` Thomas Monjalon
2025-01-14 1:50 ` lihuisong (C)
2025-01-14 11:13 ` Thomas Monjalon
2025-01-14 12:13 ` lihuisong (C)
2025-01-14 12:39 ` Thomas Monjalon
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=0293d4d1-0df7-63e1-3dba-244729a78bb0@huawei.com \
--to=lihuisong@huawei.com \
--cc=ajit.khaparde@broadcom.com \
--cc=andrew.boyer@amd.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bingz@nvidia.com \
--cc=chaoyong.he@corigine.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=praveen.shetty@intel.com \
--cc=somnath.kotur@broadcom.com \
--cc=stephen@networkplumber.org \
--cc=suanmingm@nvidia.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.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).