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 >
