From patchwork Mon Jul 27 08:42:38 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Wang X-Patchwork-Id: 6617 Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 56B0EC57C; Mon, 27 Jul 2015 10:43:26 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id A14A4C576 for ; Mon, 27 Jul 2015 10:43:22 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 27 Jul 2015 01:43:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,552,1432623600"; d="scan'208";a="755437911" Received: from shvmail01.sh.intel.com ([10.239.29.42]) by fmsmga001.fm.intel.com with ESMTP; 27 Jul 2015 01:43:21 -0700 Received: from shecgisg004.sh.intel.com (shecgisg004.sh.intel.com [10.239.29.89]) by shvmail01.sh.intel.com with ESMTP id t6R8hJr7023375; Mon, 27 Jul 2015 16:43:19 +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 t6R8hFdG031153; Mon, 27 Jul 2015 16:43:17 +0800 Received: (from xiaowan1@localhost) by shecgisg004.sh.intel.com (8.13.6/8.13.6/Submit) id t6R8hFi8031149; Mon, 27 Jul 2015 16:43:15 +0800 From: Wang Xiao W To: dev@dpdk.org Date: Mon, 27 Jul 2015 16:42:38 +0800 Message-Id: <1437986559-31016-15-git-send-email-xiao.w.wang@intel.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1437986559-31016-1-git-send-email-xiao.w.wang@intel.com> References: <1437986559-31016-1-git-send-email-xiao.w.wang@intel.com> Cc: Wang Xiao W Subject: [dpdk-dev] [PATCH 15/16] 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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);