From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 641141E20 for ; Mon, 28 Aug 2017 17:50:35 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id b82so5733769wmd.1 for ; Mon, 28 Aug 2017 08:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=2eDv5QLkftRhf7jLOhAa7SSxiL1QqsoEMIa8EChIChg=; b=CUG+KpMMXVtg7UOi/H2IoOZTIBH8XW01gCqLAaYSSZ6AqnLIQpWWmIttOJ7w8e2acX Mj7zFmobQw0Xzi0YnLHm4jT6JGy7mWrRoK8+6xdxEsR4VYypyJ3Wz8XweD+n3j+PGsO1 +tCNVX+63XDagwpTt3w1T9UzMLUK8GXmmyaoPVMjNPEXMQETGFnoOXvv9Pt4804lcUR4 MJuslhxnn7K/IRZ/k1Lmq9qB/mOaeTzgri+I5lCRgs+vsQzrX2ZWZux+JGKk34rSd0TO dcGqqf5SYm1LlwQwgKpuq4f7Rth6XpQBtbrccTelP49zsGW2NByCb98NZ95ehWFyJGuS ya4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=2eDv5QLkftRhf7jLOhAa7SSxiL1QqsoEMIa8EChIChg=; b=d50w4/c1RCjQOOllfSp1nG+qgiVvakVBkTtUQfnVP7ON9ro0dCNOx2UIKUoVvDRLO9 r2o3d/VrDDnq4NehB3QoOGWdJBD5MSx6zUYWsUCRQu3zyQVUnXWt6jCmDc5o8RWlQwAi JKNcq8S7d9JJmbT7ovQr17xusr0kAyhzedtNh5qNZPEFa4nqaL3Z5NqCn4vCVlcx3COM SkJdt9/uz/EB6FkLwW2LeQMbBon7+axoFCktvCHlLajDWw2fp3S9wl2h+Z/bwUme6jkg 8/OZPis70tiVF6QHgOljAwLbHcDwMQOQ2d7+YHiYp0l05Jgsa7AavAUu+o1xP7Q1RqC4 B8Hw== X-Gm-Message-State: AHYfb5gjEh9AJO+XFPEpJOW0UuUSSd/MuIwIZwd3Jt9V3Rm75oPeSzCQ iuk0CocJd+0Y6uL5 X-Received: by 10.28.165.206 with SMTP id o197mr558942wme.39.1503935434896; Mon, 28 Aug 2017 08:50:34 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id h30sm847203wrf.11.2017.08.28.08.50.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 08:50:34 -0700 (PDT) Date: Mon, 28 Aug 2017 17:50:24 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: "Guo, Jia" Cc: "shreyansh.jain@nxp.com" , "jblunck@infradead.org" , "dev@dpdk.org" , "Zhang, Helin" , "Wu, Jingjing" , Thomas Monjalon , "stephen@networkplumber.org" , "Richardson, Bruce" , "Jain, Deepak K" , "Liu, Yu Y" Message-ID: <20170828155024.GG8124@bidouze.vm.6wind.com> References: <1495986280-26207-1-git-send-email-jia.guo@intel.com> <1643564.1KfnGSoeuV@xps> <3931985.8o2Ck0PCcH@xps> <01BA8470C017D6468C8290E4B9C5E1E83B259F2A@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <01BA8470C017D6468C8290E4B9C5E1E83B259F2A@shsmsx102.ccr.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Mon, 28 Aug 2017 15:50:35 -0000 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@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 = 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