DPDK patches and discussions
 help / color / mirror / Atom feed
From: Chaoyong He <chaoyong.he@corigine.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: oss-drivers <oss-drivers@corigine.com>,
	Niklas Soderlund <niklas.soderlund@corigine.com>,
	James Hershaw <james.hershaw@corigine.com>
Subject: RE: [PATCH] net/nfp: write link speed to control BAR
Date: Mon, 6 Mar 2023 07:06:08 +0000	[thread overview]
Message-ID: <SJ0PR13MB55459BDF90B0CFC2EA1E2B3A9EB69@SJ0PR13MB5545.namprd13.prod.outlook.com> (raw)
In-Reply-To: <a69a6bcf-3a07-85cd-7c39-eb65922e138e@amd.com>

> On 2/21/2023 6:29 AM, Chaoyong He wrote:
> > From: James Hershaw <james.hershaw@corigine.com>
> >
> > Due to changes in the firmware for NFPs, firmware will no longer write
> > the link speed of a port to the control BAR. In line with the
> > behaviour of the kernel NFP driver, this is now handled by the PMD by
> > reading the value provided by the NSP in the nfp_eth_table struct
> > within the pf_dev of the port and subsequently writing this value to the
> control BAR.
> >
> 
> Don't you need some kind of FW version check to figure out if
> 'NFP_NET_CFG_STS_NSP_LINK_RATE' needs to be updated by driver or not?
> 
> How do you manage driver <-> FW dependency?
> 
> 
> > Signed-off-by: James Hershaw <james.hershaw@corigine.com>
> > Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
> > Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
> > ---
> >  drivers/net/nfp/nfp_common.c | 90 ++++++++++++++++++++++-----------
> ---
> >  drivers/net/nfp/nfp_ctrl.h   |  9 ++++
> >  2 files changed, 65 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/net/nfp/nfp_common.c
> > b/drivers/net/nfp/nfp_common.c index 5922bfea8e..006ea58008 100644
> > --- a/drivers/net/nfp/nfp_common.c
> > +++ b/drivers/net/nfp/nfp_common.c
> > @@ -52,6 +52,53 @@
> >  #include <sys/ioctl.h>
> >  #include <errno.h>
> >
> > +static const uint32_t nfp_net_link_speed_nfp2rte[] = {
> > +	[NFP_NET_CFG_STS_LINK_RATE_UNSUPPORTED] =
> RTE_ETH_SPEED_NUM_NONE,
> > +	[NFP_NET_CFG_STS_LINK_RATE_UNKNOWN]     =
> RTE_ETH_SPEED_NUM_NONE,
> > +	[NFP_NET_CFG_STS_LINK_RATE_1G]          =
> RTE_ETH_SPEED_NUM_1G,
> > +	[NFP_NET_CFG_STS_LINK_RATE_10G]         =
> RTE_ETH_SPEED_NUM_10G,
> > +	[NFP_NET_CFG_STS_LINK_RATE_25G]         =
> RTE_ETH_SPEED_NUM_25G,
> > +	[NFP_NET_CFG_STS_LINK_RATE_40G]         =
> RTE_ETH_SPEED_NUM_40G,
> > +	[NFP_NET_CFG_STS_LINK_RATE_50G]         =
> RTE_ETH_SPEED_NUM_50G,
> > +	[NFP_NET_CFG_STS_LINK_RATE_100G]        =
> RTE_ETH_SPEED_NUM_100G,
> > +};
> > +
> > +static uint32_t
> > +nfp_net_link_speed_rte2nfp(uint32_t speed) {
> > +	uint32_t i;
> > +
> > +	for (i = 0; i < RTE_DIM(nfp_net_link_speed_nfp2rte); i++) {
> > +		if (speed == nfp_net_link_speed_nfp2rte[i])
> > +			return i;
> > +	}
> > +
> > +	return NFP_NET_CFG_STS_LINK_RATE_UNKNOWN;
> > +}
> > +
> > +static void
> > +nfp_net_notify_port_speed(struct rte_eth_dev *dev) {
> > +	struct nfp_net_hw *hw;
> > +	struct nfp_eth_table *eth_table;
> > +	uint32_t nn_link_status;
> > +
> > +	hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > +	eth_table = hw->pf_dev->nfp_eth_table;
> > +
> > +	nn_link_status = nn_cfg_readl(hw, NFP_NET_CFG_STS);
> > +	nn_link_status = (nn_link_status >>
> NFP_NET_CFG_STS_LINK_RATE_SHIFT) &
> > +			NFP_NET_CFG_STS_LINK_RATE_MASK;
> > +
> > +	if ((nn_link_status & NFP_NET_CFG_STS_LINK) == 0) {
> > +		nn_cfg_writel(hw, NFP_NET_CFG_STS_NSP_LINK_RATE,
> NFP_NET_CFG_STS_LINK_RATE_UNKNOWN);
> > +		return;
> > +	}
> > +
> > +	nn_cfg_writel(hw, NFP_NET_CFG_STS_NSP_LINK_RATE,
> > +		      nfp_net_link_speed_rte2nfp(eth_table->ports[hw-
> >idx].speed));
> 
> PF driver writes link speed to 'NFP_NET_CFG_STS_NSP_LINK_RATE' register,
> but 'nfp_net_link_update()' still gets it from 'NFP_NET_CFG_STS'
> register (via 'nfp_net_link_speed_nfp2rte[nn_link_status]').
> 
> Shouldn't 'nfp_net_link_update()' needs to be updated to read speed from
> 'NFP_NET_CFG_STS_NSP_LINK_RATE' register?

Sorry for the late response, we spend a lot of time to check and discuss.

For older firmware, a full word is allocated (NFP_NET_CFG_STS) to report link status and port speed to the driver.
However, in the interests of keeping FW files port-speed agnostic in the future, 
the upper 16 bits are no longer written to by FW, so we write the speed to that address (NFP_NET_CFG_STS_LINK_RATE).
The lower 16 bits (link status) are still handled by firmware.

These changes are completely backwards compatible with older firmware versions, so no FW version check is required.

  reply	other threads:[~2023-03-06  7:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21  6:29 Chaoyong He
2023-02-23 16:39 ` Ferruh Yigit
2023-03-06  7:06   ` Chaoyong He [this message]
2023-03-07 13:24     ` Ferruh Yigit
2023-03-10  6:07       ` Chaoyong He
2023-03-10  6:25 ` [PATCH v2 0/2] " Chaoyong He
2023-03-10  6:25   ` [PATCH v2 1/2] net/nfp: add helper functions for read/write 16b values Chaoyong He
2023-03-10  6:25   ` [PATCH v2 2/2] net/nfp: write link speed to control BAR Chaoyong He
2023-03-10 11:15     ` Ferruh Yigit
2023-03-13  3:03       ` Chaoyong He
2023-03-13  8:39         ` Ferruh Yigit
2023-03-13 10:18   ` [PATCH v2 0/2] " Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR13MB55459BDF90B0CFC2EA1E2B3A9EB69@SJ0PR13MB5545.namprd13.prod.outlook.com \
    --to=chaoyong.he@corigine.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=james.hershaw@corigine.com \
    --cc=niklas.soderlund@corigine.com \
    --cc=oss-drivers@corigine.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).