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 C5592A0547; Thu, 29 Apr 2021 10:43:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B0AD8412E3; Thu, 29 Apr 2021 10:43:45 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 37D724067E for ; Thu, 29 Apr 2021 10:43:43 +0200 (CEST) IronPort-SDR: +yksdN6NAKwBe9LwjL9jQo/V9tPX1olbY2POeLG8W9D1fwl280f+SJKZYYkk5cvDAtTrPsbkdL hw1+KHq8dxkQ== X-IronPort-AV: E=McAfee;i="6200,9189,9968"; a="184090599" X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="184090599" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Apr 2021 01:43:42 -0700 IronPort-SDR: TcCvvgzg94d0Bir+zKEsC/Dewl/W2NbYrsh7M7n7QW9fOkbMGSSr8uqH7sD0WUkTv19vu9s10X DbH68MM+C5Dw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="537292528" Received: from wuwenjun.sh.intel.com ([10.67.110.159]) by orsmga004.jf.intel.com with ESMTP; 29 Apr 2021 01:43:41 -0700 From: Wenjun Wu To: dev@dpdk.org, beilei.xing@intel.com Cc: Wenjun Wu Date: Thu, 29 Apr 2021 16:27:24 +0800 Message-Id: <20210429082724.1157163-1-wenjun1.wu@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210429031056.1092878-1-wenjun1.wu@intel.com> References: <20210429031056.1092878-1-wenjun1.wu@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [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" 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. Since iavf can hardly triggle this issue and i40evf will be replaced by iavf 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. 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. v5: modify the commit message to mention this a workaround. --- 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