From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9E867A0548; Sun, 25 Apr 2021 04:25:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6A49D40685; Sun, 25 Apr 2021 04:25:42 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id DF4B64013F for ; Sun, 25 Apr 2021 04:25:39 +0200 (CEST) IronPort-SDR: 1eZ/Zmm9d0EEEwBQwWO9EMOSjDH27CYKwWhZWZ9iYfKmgJ4rYt/DYw7TWLU6SckZjL3lF0x+CX 2EITZPCnuh8g== X-IronPort-AV: E=McAfee;i="6200,9189,9964"; a="196318957" X-IronPort-AV: E=Sophos;i="5.82,249,1613462400"; d="scan'208";a="196318957" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Apr 2021 19:25:38 -0700 IronPort-SDR: HivvRkqN5HS+Lxi3KqhswyXSB5AFv2YFCjk2qstX2zqVDWJUlyisivk5TM69ODvgbtR6hlx928 iNh3Ik0QpqoA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,249,1613462400"; d="scan'208";a="422196795" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga008.fm.intel.com with ESMTP; 24 Apr 2021 19:25:38 -0700 Received: from shsmsx602.ccr.corp.intel.com (10.109.6.142) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sat, 24 Apr 2021 19:25:37 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX602.ccr.corp.intel.com (10.109.6.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sun, 25 Apr 2021 10:25:35 +0800 Received: from shsmsx601.ccr.corp.intel.com ([10.109.6.141]) by SHSMSX601.ccr.corp.intel.com ([10.109.6.141]) with mapi id 15.01.2106.013; Sun, 25 Apr 2021 10:25:35 +0800 From: "Zhang, Qi Z" To: "Wu, Wenjun1" , "dev@dpdk.org" , "Xing, Beilei" CC: "Wu, Wenjun1" Thread-Topic: [dpdk-dev] [PATCH v2] net/i40e: extend VF reset waiting time Thread-Index: AQHXOXlf4xG8phSVdE6Hy5HMBjRF3KrEgXmQ Date: Sun, 25 Apr 2021 02:25:35 +0000 Message-ID: References: <20210422053430.44883-1-wenjun1.wu@intel.com> <20210425020250.205597-1-wenjun1.wu@intel.com> In-Reply-To: <20210425020250.205597-1-wenjun1.wu@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: extend VF reset waiting time X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list 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----- > From: dev On Behalf Of Wenjun Wu > Sent: Sunday, April 25, 2021 10:03 AM > To: dev@dpdk.org; Xing, Beilei > Cc: Wu, Wenjun1 > Subject: [dpdk-dev] [PATCH v2] net/i40e: extend VF reset waiting time >=20 > When resetting VF, VF will issue reset command to PF, wait a fixed amount= of > time, and assume VF reset is done. However, due to the change of dpdk > related library content, the original delay is not enough. When we use DP= DK > PF instead of kernel PF, it may cause VF start error. >=20 > This patch extend VF reset waiting time from 200ms to 500ms so that VF ca= n > start normally when using DPDK PF and DPDK VF in most cases. >=20 > Signed-off-by: Wenjun Wu Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi