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 B515FA0547; Thu, 29 Apr 2021 13:04:22 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9CB154110F; Thu, 29 Apr 2021 13:04:22 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 8EBCE410DD for ; Thu, 29 Apr 2021 13:04:20 +0200 (CEST) IronPort-SDR: TTZLoITMIwFgHTGp1WQBRUpwcZoW/FgN56dsjx/GBI9zAuCSqy0CsFnrKeEqZ/Haxz2FoQ4cOl GVgyJU6bXQiQ== X-IronPort-AV: E=McAfee;i="6200,9189,9968"; a="196535656" X-IronPort-AV: E=Sophos;i="5.82,259,1613462400"; d="scan'208";a="196535656" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2021 04:04:19 -0700 IronPort-SDR: BSk465dFvLve1BhduVkMANCAVSB+j6st6jTA3UcLKN2hUapjn0GGJfs+qbH364TVGzmbsD2TJV s7KWET/jzQwA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,259,1613462400"; d="scan'208";a="388091371" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga006.jf.intel.com with ESMTP; 29 Apr 2021 04:04:19 -0700 Received: from shsmsx606.ccr.corp.intel.com (10.109.6.216) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 29 Apr 2021 04:04:18 -0700 Received: from shsmsx601.ccr.corp.intel.com (10.109.6.141) by SHSMSX606.ccr.corp.intel.com (10.109.6.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 29 Apr 2021 19:04:16 +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; Thu, 29 Apr 2021 19:04:16 +0800 From: "Zhang, Qi Z" To: "Wu, Wenjun1" , "dev@dpdk.org" , "Xing, Beilei" CC: "Wu, Wenjun1" Thread-Topic: [dpdk-dev] [PATCH v5] net/i40e: extend VF reset waiting time Thread-Index: AQHXPNPNVVn18C9hgU6Y+lAGU4zvsarLVOmA Date: Thu, 29 Apr 2021 11:04:16 +0000 Message-ID: References: <20210429031056.1092878-1-wenjun1.wu@intel.com> <20210429082724.1157163-1-wenjun1.wu@intel.com> In-Reply-To: <20210429082724.1157163-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 v5] 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: Thursday, April 29, 2021 4:27 PM > To: dev@dpdk.org; Xing, Beilei > Cc: Wu, Wenjun1 > Subject: [dpdk-dev] [PATCH v5] net/i40e: extend VF reset waiting time >=20 > When starting VF, VF will issue reset command to PF, wait a fixed amount = of > time, and assume VF reset is done on PF side. However, compared with kern= el > PF, DPDK PF needs more time to setup. If we run DPDK PF to support DPDK V= F, > the original delay will not be enough. When we first start VF after PF is > launched, the execution time of the statement info.msg_buf =3D > rte_zmalloc("msg_buffer", info.buf_len, 0); in the function > i40e_dev_handle_aq_msg is more than 200ms. It may cause VF start error. >=20 > Since iavf can hardly triggle this issue and i40evf will be replaced by i= avf in > future DPDK versions, this patch provide a workaround. > We extend VF reset waiting time from 200ms to 500ms so that VF can 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