[dpdk-dev] [PATCH v2 1/2] eal: add uevent api for hot plug

Guo, Jia jia.guo at intel.com
Tue Aug 22 16:56:04 CEST 2017


a. about uevent mechanism
 
As we know, uevent is come from the kobject of the kernel side, every kobject would have its own uevent, and a sysfs folder identify a kobject,
such as cpu,usb,pci,pci-express,virio, these bus component all have uevent. I agree that uevent would be the best if it could integrated in the bus layer.
I check the kernel src code , the uevent related is in lib/koject_uvent.c, and only for linux not for bsp, both support uio and vfio, 
so where shoud dpdk uevent be location?  I come to my mind 4 option below, and I propose 2) and 4).

1)Eal_bus:  (but uevent like netlink socket thing and event polling not related with bus behavior)
2)eal_dev:  (just considerate it like kernel's udev, and create new epoll, uevent handler)
3)add new file eal_udev.c
4)eal_interrupt. (add into the interrupt epoll, use interrupt handler)

Shreyansh & jblunck & gaetan

Since you recently work on pci bus layer and expert on  that, I want to ask you that if you plan about any other bus layer rework would be conflict my proposer,
or would let me modify to compatibility with the next architect? If you have,  please let me know. thanks. 

b. about pci uevent handler.
I suppose 2 option:
1)use a common interrupt handler for pci pmd to let app or fail-safe pmd to register. 
2)use a common uevent handler for pci pmd to let app or fail-safe pmd register.

Community, are there any good comment about that ?

Best regards,
Jeff Guo

-----Original Message-----
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Guo, Jia
Sent: Wednesday, July 5, 2017 5:04 PM
To: Thomas Monjalon <thomas at monjalon.net>
Cc: dev at dpdk.org; Zhang, Helin <helin.zhang at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/2] eal: add uevent api for hot plug



On 7/5/2017 3:32 PM, Thomas Monjalon wrote:
> 05/07/2017 05:02, Guo, Jia:
>> hi, thomas
>>
>>
>> On 7/5/2017 7:45 AM, Thomas Monjalon wrote:
>>> Hi,
>>>
>>> This is an interesting step for hotplug in DPDK.
>>>
>>> 28/06/2017 13:07, Jeff Guo:
>>>> +       netlink_fd = socket(PF_NETLINK, SOCK_DGRAM, 
>>>> + NETLINK_KOBJECT_UEVENT);
>>> It is monitoring the whole system...
>>>
>>>> +int
>>>> +rte_uevent_get(int fd, struct rte_uevent *uevent) {
>>>> +       int ret;
>>>> +       char buf[RTE_UEVENT_MSG_LEN];
>>>> +
>>>> +       memset(uevent, 0, sizeof(struct rte_uevent));
>>>> +       memset(buf, 0, RTE_UEVENT_MSG_LEN);
>>>> +
>>>> +       ret = recv(fd, buf, RTE_UEVENT_MSG_LEN - 1, MSG_DONTWAIT);
>>> ... and it is read from this function called by one driver.
>>> It cannot work without a global dispatch.
>> the rte_uevent-connect is called in func of pci_uio_alloc_resource, 
>> so each socket is created by  by each uio device. so i think that 
>> would not affect each driver isolate to use it.
> Ah OK, I missed it.
>
>>> It must be a global mechanism, probably a service core.
>>> The question is also to know whether it should be a mandatory 
>>> service in DPDK or an optional helper?
>> a global mechanism would be good, but so far, include mlx driver, we 
>> all handle the hot plug event in driver by app's registered callback. 
>> maybe a better global would be try in the future. but now is would 
>> work for all pci uio device.
> mlx drivers have a special connection to the kernel through the 
> associated mlx kernel drivers. That's why the PMD handle the events in a specific way.
>
> You are adding event handling for UIO.
> Now we need also VFIO.
>
> I am wondering how it could be better integrated in the bus layer.
absolutely, hot plug for VFIO must be request more for the live migration,  and we plan to add it at next level, when we go thought all uio hot plug feature integration done. so, could i expect an ack if there aren't other concern about uio uevent here. thanks.
>> and more, if in pci uio device to use hot plug , i think it might be 
>> mandatory.



More information about the dev mailing list