From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Guo, Jia" Subject: Re: [PATCH v2 1/2] eal: add uevent api for hot plug Date: Tue, 22 Aug 2017 14:56:04 +0000 Message-ID: <01BA8470C017D6468C8290E4B9C5E1E83B259F2A@shsmsx102.ccr.corp.intel.com> References: <1495986280-26207-1-git-send-email-jia.guo@intel.com> <1643564.1KfnGSoeuV@xps> <3931985.8o2Ck0PCcH@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" , Thomas Monjalon , "stephen@networkplumber.org" , "Richardson, Bruce" , "Jain, Deepak K" , "Liu, Yu Y" To: "shreyansh.jain@nxp.com" , "jblunck@infradead.org" , "gaetan.rivet@6wind.com" Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 536FC7CA3 for ; Tue, 22 Aug 2017 16:56:09 +0200 (CEST) In-Reply-To: Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" a. about uevent mechanism =20 As we know, uevent is come from the kobject of the kernel side, every kobje= ct 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 la= yer. 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,=20 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 rel= ated 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 hav= e, please let me know. thanks.=20 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.=20 2)use a common uevent handler for pci pmd to let app or fail-safe pmd regis= ter. Community, are there any good comment about that ? Best regards, Jeff Guo -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Guo, Jia Sent: Wednesday, July 5, 2017 5:04 PM To: Thomas Monjalon Cc: dev@dpdk.org; Zhang, Helin ; Wu, Jingjing 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 =3D socket(PF_NETLINK, SOCK_DGRAM,=20 >>>> + 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 =3D 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,=20 >> so each socket is created by by each uio device. so i think that=20 >> 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=20 >>> service in DPDK or an optional helper? >> a global mechanism would be good, but so far, include mlx driver, we=20 >> all handle the hot plug event in driver by app's registered callback.=20 >> maybe a better global would be try in the future. but now is would=20 >> work for all pci uio device. > mlx drivers have a special connection to the kernel through the=20 > 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 f= eature integration done. so, could i expect an ack if there aren't other co= ncern about uio uevent here. thanks. >> and more, if in pci uio device to use hot plug , i think it might be=20 >> mandatory.