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 E47E0A0A0E; Thu, 29 Apr 2021 05:27:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 727A54067E; Thu, 29 Apr 2021 05:27:00 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 9E8614003E for ; Thu, 29 Apr 2021 05:26:58 +0200 (CEST) IronPort-SDR: NBHeYtG2QZkFnm/XvhpuHBVP0pPyM7LnKeXnA1vJxO2g9BtNnmhD2TWHnc2tV9MzwPlBiv5PhX ad+0R/e/dmoA== X-IronPort-AV: E=McAfee;i="6200,9189,9968"; a="196466482" X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="196466482" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Apr 2021 20:26:57 -0700 IronPort-SDR: 1wknwUdL24DQdt2pV45pGuLNq6hFGKp7RC7hrSG8SRWCCtzEYuqS0+nQI6+XkcbhK/zH4+lFDM tGCypaOlDHsQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="423851636" Received: from wuwenjun.sh.intel.com ([10.67.110.159]) by fmsmga008.fm.intel.com with ESMTP; 28 Apr 2021 20:26:56 -0700 From: Wenjun Wu To: dev@dpdk.org, beilei.xing@intel.com Cc: Wenjun Wu Date: Thu, 29 Apr 2021 11:10:56 +0800 Message-Id: <20210429031056.1092878-1-wenjun1.wu@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210429030538.1092068-1-wenjun1.wu@intel.com> References: <20210429030538.1092068-1-wenjun1.wu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-dev] [PATCH v4] 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 will 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. v4: correct spelling mistakes. --- 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