From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 0AA3D5598 for ; Tue, 11 Jul 2017 03:57:18 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP; 10 Jul 2017 18:57:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,343,1496127600"; d="scan'208";a="125562292" Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105]) by fmsmga006.fm.intel.com with ESMTP; 10 Jul 2017 18:57:17 -0700 Received: from pgsmsx106.gar.corp.intel.com ([169.254.9.158]) by PGSMSX107.gar.corp.intel.com ([10.221.44.105]) with mapi id 14.03.0319.002; Tue, 11 Jul 2017 09:57:16 +0800 From: "Dai, Wei" To: Jerin Jacob CC: "thomas@monjalon.net" , "Lu, Wenzhuo" , "Ananyev, Konstantin" , "Wu, Jingjing" , "Xing, Beilei" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset Thread-Index: AQHS+WWa1PmUN361mUavg2CqZl6Kd6JMaEGAgAFxpSA= Date: Tue, 11 Jul 2017 01:57:15 +0000 Message-ID: <49759EB36A64CF4892C1AFEC9231E8D650B60DC0@PGSMSX106.gar.corp.intel.com> References: <1498817556-64379-1-git-send-email-wei.dai@intel.com> <1499681144-26031-1-git-send-email-wei.dai@intel.com> <1499681144-26031-2-git-send-email-wei.dai@intel.com> <20170710113506.GA17339@jerin> In-Reply-To: <20170710113506.GA17339@jerin> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [172.30.20.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 01:57:19 -0000 -----Original Message----- From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]=20 Sent: Monday, July 10, 2017 7:35 PM To: Dai, Wei Cc: thomas@monjalon.net; Lu, Wenzhuo ; Ananyev, Konst= antin ; Wu, Jingjing ;= Xing, Beilei ; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset -----Original Message----- > Date: Mon, 10 Jul 2017 18:05:41 +0800 > From: Wei Dai > To: thomas@monjalon.net, wenzhuo.lu@intel.com, =20 > konstantin.ananyev@intel.com, jingjing.wu@intel.com,=20 > beilei.xing@intel.com > CC: dev@dpdk.org, Wei Dai > Subject: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset > X-Mailer: git-send-email 2.7.5 >=20 > This patch adds a new eth_dev layer API function rte_eth_dev_reset(). > A DPDK application can call this function to reset a NIC and keep its=20 > port id afterwards. > It means that all SW resources allocated in ethdev layer should be=20 > kept and SW and HW resources of the NIC in PMD need to be reset in=20 > similar way that it runs PCI dev_uninit() and then dev_init(). > The sequence of dev_uninit() and dev_init() can be packed into a=20 > single interface API rte_eth_dev_reset(). > Please See the comments before the declaration of rte_eht_dev_reset()=20 > in lib/librte_ether/rte_ethdev.h to get more details on why this=20 > function is needed, what this function does and what an application=20 > should do after calling this function. >=20 > Signed-off-by: Wei Dai > --- > /** > + * Reset a Ethernet device and keep its port id. > + * > + * A DPDK application calls this function to do an initiative or=20 > + passive > + * reset of a port. > + * > + * Sometimes a port have to be reset passively. For example a PF is=20 > + reset, > + * all its VFs should also be reset by application itself to align=20 > + with the > + * PF. May be I didn't understood this use case properly,But, PF can always send m= ailbox message to VF on PF reset. Right? [Wei: As to ixgbe, PF kernel driver always send mailbox message to VF when = PF is reset. For other NICs, there are maybe=20 other mechanism to notify VF of PF reset.] On such message from PF, VF can transparently reset without application kno= wledge(i.e rx and/or tx burst return zero) [Wei: VF reset is handling many HW registers which may have effect on worki= ng Rx/Tx path and may cause some unexpected behavior like crash. So application should make some operations like stoppi= ng Rx/Tx path before it begin VF reset. This is why application should handle VF reset itself.] > + * A DPDK application also can call this function to trigger an=20 > + initative > + * port reset. When apart from the above use case? Even if it is above case, we should hav= e some event to notify application to initiate the reset.Right? Without the= event, When or on what basics application needs to initiate reset? [Wei: Indeed, until now we didn't see any use case which DPDK application i= nitiative port reset itself.=20 The most usual case is that PF is working with kernel driver and VFs are wo= rking with DPDK PMD. Some operations on kernel PF lead to a PF reset which causes its VF reset. Anyway this new function provides a possibility for application to trigger = an initiative port reset.] > + *