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 C6B92A0A0E; Thu, 29 Apr 2021 05:21:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ABE454067E; Thu, 29 Apr 2021 05:21:43 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 23D404003E for ; Thu, 29 Apr 2021 05:21:41 +0200 (CEST) IronPort-SDR: wPnbGq61T9nKZ36BbhiBVIpQGAixYYZOht8Zr2gTg048cFDZZHENusO5twWtAt6v40hOssLJgF Z7qtGSK6hapg== X-IronPort-AV: E=McAfee;i="6200,9189,9968"; a="196465844" X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="196465844" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2021 20:21:39 -0700 IronPort-SDR: 3TZYxHD5NxCAuaTKbqLu+yskwJ3q0OifYGwZLn6kyud78+o8kOs8nKH6qiyyEfIKHioXJoXAaD ttugXzaLem0w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="430630871" Received: from wuwenjun.sh.intel.com ([10.67.110.159]) by orsmga008.jf.intel.com with ESMTP; 28 Apr 2021 20:21:37 -0700 From: Wenjun Wu To: dev@dpdk.org, beilei.xing@intel.com Cc: Wenjun Wu Date: Thu, 29 Apr 2021 11:05:38 +0800 Message-Id: <20210429030538.1092068-1-wenjun1.wu@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210425020250.205597-1-wenjun1.wu@intel.com> References: <20210425020250.205597-1-wenjun1.wu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v3] 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" 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 kernel PF, DPDK PF needs more time to setup. If we run DPDK PF to support DPDK VF, the original delay wil not be enough. When we first start VF after PF is launched, the execution time of the statement info.msg_buf = 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. This patch 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. Signed-off-by: Wenjun Wu --- v2: change the delay to 500ms because it can cover most cases. v3: perfect the commit message. --- drivers/net/i40e/i40e_ethdev_vf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c index 3c258ba7cf..aeb6816b9f 100644 --- a/drivers/net/i40e/i40e_ethdev_vf.c +++ b/drivers/net/i40e/i40e_ethdev_vf.c @@ -1236,7 +1236,7 @@ i40evf_reset_vf(struct rte_eth_dev *dev) * it to ACTIVE. In this duration, vf may not catch the moment that * COMPLETE is set. So, for vf, we'll try to wait a long time. */ - rte_delay_ms(200); + rte_delay_ms(500); ret = i40evf_check_vf_reset_done(dev); if (ret) { -- 2.25.1