From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [PATCH v6 1/4] lib/librte_ether: support device reset
Date: Tue, 21 Jun 2016 09:21:25 +0530
Message-ID: <20160621035124.GC4903@localhost.localdomain>
References: <1465191653-28408-1-git-send-email-wenzhuo.lu@intel.com>
 <1466403870-6840-1-git-send-email-wenzhuo.lu@intel.com>
 <1466403870-6840-2-git-send-email-wenzhuo.lu@intel.com>
 <20160620091410.GA9323@localhost.localdomain>
 <20160620091714.276c186c@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Wenzhuo Lu <wenzhuo.lu@intel.com>, <dev@dpdk.org>,
 <konstantin.ananyev@intel.com>, <bruce.richardson@intel.com>,
 <jing.d.chen@intel.com>, <cunming.liang@intel.com>, <jingjing.wu@intel.com>,
 <helin.zhang@intel.com>, <thomas.monjalon@6wind.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from na01-bn1-obe.outbound.protection.outlook.com
 (mail-bn1on0072.outbound.protection.outlook.com [157.56.110.72])
 by dpdk.org (Postfix) with ESMTP id 052189ADB
 for <dev@dpdk.org>; Tue, 21 Jun 2016 05:51:45 +0200 (CEST)
Content-Disposition: inline
In-Reply-To: <20160620091714.276c186c@xeon-e3>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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

>