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-boun...@dpdk.org] On Behalf Of Guo, Jia > Sent: Wednesday, July 5, 2017 5:04 PM > To: Thomas Monjalon <tho...@monjalon.net> > Cc: dev@dpdk.org; Zhang, Helin <helin.zh...@intel.com>; Wu, Jingjing > <jingjing...@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
