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 91C0F2C8 for ; Wed, 21 Jun 2017 04:50:52 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jun 2017 19:50:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,367,1493708400"; d="scan'208,217";a="116877373" Received: from jguo15x-mobl3.ccr.corp.intel.com (HELO [10.239.205.171]) ([10.239.205.171]) by fmsmga005.fm.intel.com with ESMTP; 20 Jun 2017 19:50:49 -0700 To: =?UTF-8?Q?Ga=c3=abtan_Rivet?= , "Wu, Jingjing" References: <1495986280-26207-1-git-send-email-jia.guo@intel.com> <20170530071400.GN14914@bidouze.vm.6wind.com> <9BB6961774997848B5B42BEC655768F810D9C9FA@SHSMSX103.ccr.corp.intel.com> <20170615212240.GE29091@bidouze.vm.6wind.com> Cc: "Zhang, Helin" , "Richardson, Bruce" , "Ananyev, Konstantin" , "Liu, Yuanhan" , "dev@dpdk.org" From: "Guo, Jia" Message-ID: <62b14e8e-fb59-1e46-b579-90a6298da85a@intel.com> Date: Wed, 21 Jun 2017 10:50:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170615212240.GE29091@bidouze.vm.6wind.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC] Add hot plug event in rte eal interrupt and inplement it in i40e driver. 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: Wed, 21 Jun 2017 02:50:53 -0000 hi,gaetan On 6/16/2017 5:22 AM, Gaëtan Rivet wrote: > Hi Jingjing, > > On Wed, Jun 07, 2017 at 07:40:37AM +0000, Wu, Jingjing wrote: >>>> Secondly, in order to read out the uevent that monitoring, we need to add uevent API in rte >>> layer. We plan add 2 , rte_uevent_connect and rte_get_uevent. All driver interrupt handler >>> could use these API to enable the uevent monitoring, and read out the uevent type , then >>> corresponding to handle these uevent, such as detach the device when get the remove type. >>> I find having a generic uevent API interesting. >>> >>> However, all specifics pertaining to UIO use (hotplug_fd, subsystem >>> enum) should stay in UIO specific code (eal_pci_uio.c?). >>> >> Yes, but it can be also considered as interrupt mechanism, right? >> > Sure. > >>> I am currently moving the PCI bus out of the EAL. EAL subsystems should >>> not rely on PCI specifics, as they won't be available afterward. >> Will the interrupt handling be kept in EAL, right? >> > Ah yes, I was actually mistaken and thought more UIO parts would be > moving. so , i assumption that the interrupt handling still be kept in EAL, so that would not affect my adding the uevent in the eal interrupt part, right? so if it have any other dependency, please shout to let me know. >>> It should also allow you to clean up your API. Exposing hotplug_fd and >>> requiring PMDs to link it can be avoided and should result in a simpler >>> API. >> Didn't get the idea. Why it will result in a simpler API? Is there any patch help >> Me to understand? >> > How do you demux the hotplug_fd for several drivers / device? it is related with the dual port/device/driver problem, i think what should be some mapping of the dev_path there, i will refine the part to handle it in v2. Thanks.