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 99A101C0B for ; Fri, 30 Jun 2017 05:36:40 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 20:36:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,284,1496127600"; d="scan'208";a="121112973" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga006.fm.intel.com with ESMTP; 29 Jun 2017 20:36:39 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 29 Jun 2017 20:36:39 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 29 Jun 2017 20:36:38 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.116]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0319.002; Fri, 30 Jun 2017 11:36:37 +0800 From: "Wu, Jingjing" To: Stephen Hemminger CC: =?iso-8859-1?Q?Ga=EBtan_Rivet?= , "Guo, Jia" , "Zhang, Helin" , "Richardson, Bruce" , "Ananyev, Konstantin" , "Liu, Yuanhan" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC] Add hot plug event in rte eal interrupt and inplement it in i40e driver. Thread-Index: AQHS18p4vqfgY3j59kSp8soF+X66M6IL8u0AgA0RtVCAIr+6AIABJ1Pg 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> In-Reply-To: <20170629102748.2b5caa72@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 30 Jun 2017 03:36:41 -0000 > -----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