From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 5838E91B0 for ; Thu, 10 Sep 2015 06:39:20 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 09 Sep 2015 21:39:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,501,1437462000"; d="scan'208";a="765993823" Received: from shvmail01.sh.intel.com ([10.239.29.42]) by orsmga001.jf.intel.com with ESMTP; 09 Sep 2015 21:39:18 -0700 Received: from shecgisg004.sh.intel.com (shecgisg004.sh.intel.com [10.239.29.89]) by shvmail01.sh.intel.com with ESMTP id t8A4dGhf007407; Thu, 10 Sep 2015 12:39:16 +0800 Received: from shecgisg004.sh.intel.com (localhost [127.0.0.1]) by shecgisg004.sh.intel.com (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id t8A4dDIQ026615; Thu, 10 Sep 2015 12:39:15 +0800 Received: (from xiaowan1@localhost) by shecgisg004.sh.intel.com (8.13.6/8.13.6/Submit) id t8A4dDX9026611; Thu, 10 Sep 2015 12:39:13 +0800 From: Wang Xiao W To: dev@dpdk.org Date: Thu, 10 Sep 2015 12:38:24 +0800 Message-Id: <1441859917-26475-16-git-send-email-xiao.w.wang@intel.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1441859917-26475-1-git-send-email-xiao.w.wang@intel.com> References: <1441859917-26475-1-git-send-email-xiao.w.wang@intel.com> Cc: Wang Xiao W Subject: [dpdk-dev] [PATCH 15/28] fm10k: fix iov_msg_lport_state_pf re-enable bug X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 04:39:20 -0000 When a VF issues an LPORT_STATE request to enable a port which is already enabled, the PF will first disable the VF. Then it is supposed to re-enable the VF again with new settings. This is primarily done in order to ensure that the switch management software properly clears the previous VF settings. (ie: switch flow rules and so forth). However, there is a bug in the flow because we check if VF is enabled and don't re-enable it at the end. The issue is that we disable the VF in order to clear switch rules, and never follow-up with a re-enable. This results in a call to enable the VF results in disabling the logical port. Signed-off-by: Wang Xiao W --- drivers/net/fm10k/base/fm10k_pf.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/net/fm10k/base/fm10k_pf.c b/drivers/net/fm10k/base/fm10k_pf.c index 86283fa..aa04937 100644 --- a/drivers/net/fm10k/base/fm10k_pf.c +++ b/drivers/net/fm10k/base/fm10k_pf.c @@ -1418,6 +1418,14 @@ s32 fm10k_iov_msg_lport_state_pf(struct fm10k_hw *hw, u32 **results, err = fm10k_update_lport_state_pf(hw, vf_info->glort, 1, false); + /* need to clear VF_FLAG_ENABLED in order to ensure that we + * actually re-enable the lport state below. Note that this + * has no impact if VF is already disabled, as the flags are + * already zeroed. + */ + if (!err) + vf_info->vf_flags = FM10K_VF_FLAG_CAPABLE(vf_info); + /* when enabling the port we should reset the rate limiters */ hw->iov.ops.configure_tc(hw, vf_info->vf_idx, vf_info->rate); -- 1.9.3