From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v6 1/4] ethdev: add support of NIC reset Date: Tue, 11 Jul 2017 10:47:02 +0530 Message-ID: <20170711051701.GA5637@jerin> 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> <49759EB36A64CF4892C1AFEC9231E8D650B60DC0@PGSMSX106.gar.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "thomas@monjalon.net" , "Lu, Wenzhuo" , "Ananyev, Konstantin" , "Wu, Jingjing" , "Xing, Beilei" , "dev@dpdk.org" To: "Dai, Wei" Return-path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0053.outbound.protection.outlook.com [104.47.37.53]) by dpdk.org (Postfix) with ESMTP id 8F3F53257 for ; Tue, 11 Jul 2017 07:17:25 +0200 (CEST) Content-Disposition: inline In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D650B60DC0@PGSMSX106.gar.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Tue, 11 Jul 2017 01:57:15 +0000 > From: "Dai, Wei" > To: Jerin Jacob > CC: "thomas@monjalon.net" , "Lu, Wenzhuo" > , "Ananyev, Konstantin" > , "Wu, Jingjing" , > "Xing, Beilei" , "dev@dpdk.org" > Subject: RE: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset > > > > + * A DPDK application also can call this function to trigger an > > + initative > > + * port reset. > > When apart from the above use case? Even if it is above case, we should have 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 initiative port reset itself. > The most usual case is that PF is working with kernel driver and VFs are working 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.] That's fine. The only concern part is when to call reset API from application. Can we say on RTE_ETH_EVENT_INTR_RESET event, application needs to call the reset API? I think, it is important to specify when application need to call this API, otherwise this api behavior will be tightly coupled with underneath PMD. Side effect is, a new, non portable PMD specific API. If a PMD wishes to fixup some overflow case(as an example), by invoking the reset API from the application BUT same case may not valid for another PMD hence it will create unexpected behavior from application based on the underneath PMD. if RTE_ETH_EVENT_INTR_RESET event is not expected event to call the reset API then create a new event or if it needs to be called in RTE_ETH_EVENT_INTR_RESET then update the API documentation. > > > + *