From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Aug 2017 07:56:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,412,1498546800"; d="scan'208";a="1006429052" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga003.jf.intel.com with ESMTP; 22 Aug 2017 07:56:08 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 22 Aug 2017 07:56:07 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 22 Aug 2017 07:56:07 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.183]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.128]) with mapi id 14.03.0319.002; Tue, 22 Aug 2017 22:56:05 +0800 From: "Guo, Jia" To: "shreyansh.jain@nxp.com" , "jblunck@infradead.org" , "gaetan.rivet@6wind.com" CC: "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" , Thomas Monjalon , "stephen@networkplumber.org" , "Richardson, Bruce" , "Jain, Deepak K" , "Liu, Yu Y" Thread-Topic: [dpdk-dev] [PATCH v2 1/2] eal: add uevent api for hot plug Thread-Index: AQHS7/8+XNwDzzREK0ys+5plHkTMfKJD2QmAgAC9XYD//8UggIAAGcWAgEwLWxA= 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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDJjN2YwN2ItYTNlZS00MTQ3LThiNmMtZmI2ODFiZWIzNGEwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImhXRzdQeEkyQ3VrSUN1akQ5NGs2R2RqdFArSTVpV05BVlgyRGNQb2NpNlk9In0= dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 1/2] eal: add uevent api for hot plug X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 14:56:11 -0000 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.