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 ? > > >
