From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH v6 1/4] lib/librte_ether: support device reset
Date: Mon, 20 Jun 2016 09:17:14 -0700
Message-ID: <20160620091714.276c186c@xeon-e3>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com
 [209.85.220.43]) by dpdk.org (Postfix) with ESMTP id 9F847AD84
 for <dev@dpdk.org>; Mon, 20 Jun 2016 18:17:00 +0200 (CEST)
Received: by mail-pa0-f43.google.com with SMTP id bz2so52286397pad.1
 for <dev@dpdk.org>; Mon, 20 Jun 2016 09:17:00 -0700 (PDT)
In-Reply-To: <20160620091410.GA9323@localhost.localdomain>
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, 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.