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

Gaëtan Rivet gaetan.rivet at 6wind.com
Mon Aug 28 17:50:24 CEST 2017


Hi Jeff,

On Tue, Aug 22, 2017 at 02:56:04PM +0000, Guo, Jia wrote:
> 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. 
> 

Yes, some work is planned at least from my side.

I am moving the PCI bus out of the EAL:
http://dpdk.org/ml/archives/dev/2017-August/073512.html

The current proposal is not yet complete. Some filesystem functions
might need to be exposed.

However, it has not functional impact: functions may move, but they do
the same thing. But even so, the uevent_fd that you add within
eal_common_uio will probably have to be moved (eal_common_pci_uio.c is
going out of the EAL), nothing dramatic.

That's all I can think of from my PoV that might be in conflict with
your work.

> 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.
> 

-- 
Gaëtan Rivet
6WIND


More information about the dev mailing list