[dpdk-dev] [PATCH v8 7/7] igb_uio: fix uio release issue for hotplug
Jeff Guo
jia.guo at intel.com
Wed Jul 11 05:10:44 CEST 2018
On 7/11/2018 5:48 AM, Stephen Hemminger wrote:
> On Tue, 10 Jul 2018 19:03:27 +0800
> Jeff Guo <jia.guo at intel.com> wrote:
>
>>
>> +/* uio pci device state */
>> +enum rte_udev_state {
>> + RTE_UDEV_PROBED,
>> + RTE_UDEV_OPENNED,
>> + RTE_UDEV_RELEASED,
>> + RTE_UDEV_REMOVED,
>> +};
>> +
> The states here are a little confusing. especially since pci_release
> seems to take different actions based on the state. And there is nothing
> preventing races between unexpected removal (PCI), and removing the
> device from being used by igb_uio.
The states here just manage in igb uio, and only restore the status of
igb uio.
And only the RTE_UDEV_REMOVED that the key status might be a highlight
and process, it is means pci have been removed, then directly come to
igb uio remove without go igb uio release at first,
the status is for hotplug out, need to do specific process. It will no
affect the normal process, and for normal igb uio remove, udev be
release, no any status need to restore.
> Would it be possible to only use state variable from the kernel PCI
> layer where the value is consistent?
The state which i only care here is hot remove state, i check that
kobj->state_remove_uevent_sent could be use in igb uio,
except that still can not find a specific state of kernel pci to
identify it. If we can find it, it should be best.
what's other comment from guys?
> Also there is refcounting in PCI layer (and locking). Could that
> be used instead?
It might be, but if state is enough here we might not considerate to use
it. If i am missing anything, let me know.
More information about the dev
mailing list