From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 9F6D7388F for ; Fri, 9 Dec 2016 11:11:22 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 09 Dec 2016 02:11:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,323,1477983600"; d="scan'208";a="910417397" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.29]) ([10.237.220.29]) by orsmga003.jf.intel.com with ESMTP; 09 Dec 2016 02:11:20 -0800 To: Alejandro Lucero References: <1480669552-10411-1-git-send-email-alejandro.lucero@netronome.com> Cc: dev From: Ferruh Yigit Message-ID: <93362e8b-1193-e7df-1491-78fa39798b47@intel.com> Date: Fri, 9 Dec 2016 10:11:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3] nfp: report link speed using hardware info X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 10:11:23 -0000 On 12/9/2016 10:08 AM, Alejandro Lucero wrote: > > > On Tue, Dec 6, 2016 at 11:57 AM, Ferruh Yigit > wrote: > > On 12/2/2016 9:05 AM, Alejandro Lucero wrote: > > Previous reported speed was hardcoded. > > > > v3: remove unsed macro > > v2: using RTE_DIM instead of own macro > > > > Signed-off-by: Alejandro Lucero > > > --- > > drivers/net/nfp/nfp_net.c | 28 ++++++++++++++++++++++++++-- > > 1 file changed, 26 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c > > index c6b1587..24f3164 100644 > > --- a/drivers/net/nfp/nfp_net.c > > +++ b/drivers/net/nfp/nfp_net.c > > @@ -816,6 +816,17 @@ static void nfp_net_read_mac(struct > nfp_net_hw *hw) > > struct rte_eth_link link, old; > > uint32_t nn_link_status; > > > > + static const uint32_t ls_to_ethtool[] = { > > + [NFP_NET_CFG_STS_LINK_RATE_UNSUPPORTED] = > ETH_SPEED_NUM_NONE, > > + [NFP_NET_CFG_STS_LINK_RATE_UNKNOWN] = > ETH_SPEED_NUM_NONE, > > + [NFP_NET_CFG_STS_LINK_RATE_1G] = > ETH_SPEED_NUM_1G, > > + [NFP_NET_CFG_STS_LINK_RATE_10G] = > ETH_SPEED_NUM_10G, > > + [NFP_NET_CFG_STS_LINK_RATE_25G] = > ETH_SPEED_NUM_25G, > > + [NFP_NET_CFG_STS_LINK_RATE_40G] = > ETH_SPEED_NUM_40G, > > + [NFP_NET_CFG_STS_LINK_RATE_50G] = > ETH_SPEED_NUM_50G, > > + [NFP_NET_CFG_STS_LINK_RATE_100G] = > ETH_SPEED_NUM_100G, > > + }; > > + > > PMD_DRV_LOG(DEBUG, "Link update\n"); > > > > hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private); > > @@ -831,8 +842,21 @@ static void nfp_net_read_mac(struct > nfp_net_hw *hw) > > link.link_status = ETH_LINK_UP; > > > > link.link_duplex = ETH_LINK_FULL_DUPLEX; > > - /* Other cards can limit the tx and rx rate per VF */ > > - link.link_speed = ETH_SPEED_NUM_40G; > > + > > + nn_link_status = (nn_link_status >> > NFP_NET_CFG_STS_LINK_RATE_SHIFT) & > > + NFP_NET_CFG_STS_LINK_RATE_MASK; > > + > > + if ((NFD_CFG_MAJOR_VERSION_of(hw->ver) < 4) || > > + ((NFD_CFG_MINOR_VERSION_of(hw->ver) == 4) && > > + (NFD_CFG_MINOR_VERSION_of(hw->ver) == 0))) > > + link.link_speed = ETH_SPEED_NUM_40G; > > Same comment from previous review: > > For specific firmware version, speed is still hardcoded to 40G, can you > please mention from this and if possible its reason in commit log? > > > Well, we have old firmware still around and we need to avoid reading > this info from hardware if not supported. > But I guess I could be a more chatty about this in the commit log. I > will send another version. > > > > + else { > > + if (nn_link_status == NFP_NET_CFG_STS_LINK_RATE_UNKNOWN || > > Again from previous review: > > > This is for checking any wrong value from firmware/hardware. > > I see, but removing this check will not change the logic, else branch is > taken and again same value set. > > > OK. I think I can remove the first part of the if clause, because it is > implicit in the second part. Yes this is what I mean. Thanks. > I guess this is what you really meant, and not just to leave the else > statement (without the else, of course). am I right? > > > Still if you deliberately prefer to keep it, that is OK. > > > + nn_link_status >= RTE_DIM(ls_to_ethtool)) > > + link.link_speed = ETH_SPEED_NUM_NONE; > > + else > > + link.link_speed = ls_to_ethtool[nn_link_status]; > > + } > > > > if (old.link_status != link.link_status) { > > nfp_net_dev_atomic_write_link_status(dev, &link); > > > >