[dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset

[Lu, Wenzhuo]

Hi Jerin, Stephen,


> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Tuesday, June 21, 2016 11:51 AM
> To: Stephen Hemminger
> Cc: Lu, Wenzhuo; dev at dpdk.org; Ananyev, Konstantin; Richardson, Bruce; Chen,
> Jing D; Liang, Cunming; Wu, Jingjing; Zhang, Helin;
> thomas.monjalon at 6wind.com
> Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset
> 
> On Mon, Jun 20, 2016 at 09:17:14AM -0700, Stephen Hemminger wrote:
> > On Mon, 20 Jun 2016 14:44:11 +0530
> > Jerin Jacob <jerin.jacob at caviumnetworks.com> wrote:
> >
> > > On Mon, Jun 20, 2016 at 02:24:27PM +0800, Wenzhuo Lu wrote:
> > > > Add an API to reset the device.
> > > > It's for VF device in this scenario, kernel PF + DPDK VF.
> > > > When the PF port down->up, APP should call this API to reset VF
> > > > port. Most likely, APP should call it in its management thread and
> > > > guarantee the thread safe. It means APP should stop the rx/tx and
> > > > the device, then reset the device, then recover the device and
> > > > rx/tx.
> > >
> > > Following is _a_ use-case for Device reset. But may be not be _the_
> > > use case. IMO, We need to first say expected behavior of this API
> > > and add a use-case later.
> > >
> > > Other use-case would be, PCIe VF with functional level reset for
> > > SRIOV migration.
> > > Are we on same page?
> >
> >
> > In my experience with Linux devices, this is normally handled by the
> > device driver in the start routine.  Since any use case which needs
> > this is going to do a stop/reset/start sequence, why not just have the
> > VF device driver do this in the start routine?.
> >
> > Adding yet another API and state transistion if not necessary
> > increases the complexity and required test cases for all devices.
> 
> I agree with Stephen here.I think if application needs to call start after the
> device reset then we could add this logic in start itself rather exposing a yet
> another API
Do you mean changing the device_start to include all these actions, stop device -> stop queue -> re-setup queue -> start queue -> start device ?

> 
> >