> -----Original Message----- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Friday, June 30, 2017 1:28 AM > To: Wu, Jingjing <jingjing...@intel.com> > Cc: Gaëtan Rivet <gaetan.ri...@6wind.com>; Guo, Jia <jia....@intel.com>; > Zhang, Helin <helin.zh...@intel.com>; Richardson, Bruce > <bruce.richard...@intel.com>; Ananyev, Konstantin > <konstantin.anan...@intel.com>; Liu, Yuanhan <yuanhan....@intel.com>; > dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC] Add hot plug event in rte eal interrupt and > inplement it in i40e driver. > > On Wed, 7 Jun 2017 07:40:37 +0000 > "Wu, Jingjing" <jingjing...@intel.com> 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? > > > > > 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? > > > > > 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. > > 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 EAL so > that if device is removed, no code in driver needs to be added. > 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 able to > unwind from there. Thinking more of the Linux model where there is no need > (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
