From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wu, Jingjing" Subject: Re: [RFC] Add hot plug event in rte eal interrupt and inplement it in i40e driver. Date: Fri, 30 Jun 2017 03:36:36 +0000 Message-ID: <9BB6961774997848B5B42BEC655768F810DB7253@SHSMSX103.ccr.corp.intel.com> References: <1495986280-26207-1-git-send-email-jia.guo@intel.com> <20170530071400.GN14914@bidouze.vm.6wind.com> <9BB6961774997848B5B42BEC655768F810D9C9FA@SHSMSX103.ccr.corp.intel.com> <20170629102748.2b5caa72@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?Ga=EBtan_Rivet?= , "Guo, Jia" , "Zhang, Helin" , "Richardson, Bruce" , "Ananyev, Konstantin" , "Liu, Yuanhan" , "dev@dpdk.org" To: Stephen Hemminger Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 99A101C0B for ; Fri, 30 Jun 2017 05:36:40 +0200 (CEST) In-Reply-To: <20170629102748.2b5caa72@xeon-e3> 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" > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Friday, June 30, 2017 1:28 AM > To: Wu, Jingjing > Cc: Ga=EBtan Rivet ; Guo, Jia = ; > Zhang, Helin ; Richardson, Bruce > ; Ananyev, Konstantin > ; Liu, Yuanhan ; > dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC] Add hot plug event in rte eal interrupt and > inplement it in i40e driver. >=20 > On Wed, 7 Jun 2017 07:40:37 +0000 > "Wu, Jingjing" wrote: >=20 > > > > > > > >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 hand= le > 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? > > > > > 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 afterwar= d. > > > > Will the interrupt handling be kept in EAL, right? > > > > > 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. >=20 > You were right given the current model this is the correct way to do it. Does it mean this way in this RFC is reasonable given the current model? > It would be good if the interrupt model stuff could be moved back into EA= L so > that if device is removed, no code in driver needs to be added. >=20 At list we still need expose some interrupt/event by drivers. Such as LSC, = Rx interrupt. > All the bus -> device -> interrupt state is visible, and EAL should be ab= le to > unwind from there. Thinking more of the Linux model where there is no ne= ed > (in general) for hot plug specific code in each driver. Yes, such simpler API is what I like to see too. But now, the remove event = report by this way is more economical. Thanks Jingjing=20