[dpdk-dev] [RFC] Add hot plug event in rte eal interrupt and inplement it in i40e driver.
jingjing.wu at intel.com
Fri Jun 30 05:36:36 CEST 2017
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Friday, June 30, 2017 1:28 AM
> To: Wu, Jingjing <jingjing.wu at intel.com>
> Cc: Gaëtan Rivet <gaetan.rivet at 6wind.com>; Guo, Jia <jia.guo at intel.com>;
> Zhang, Helin <helin.zhang at intel.com>; Richardson, Bruce
> <bruce.richardson at intel.com>; Ananyev, Konstantin
> <konstantin.ananyev at intel.com>; Liu, Yuanhan <yuanhan.liu at intel.com>;
> dev at 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.wu at 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.
More information about the dev