DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Marc E. Cooper" <mcooper@hexiscyber.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] Port link speed and link duplex always set to auto-negotiate & manual link speed configuration of 100Mb link speed not possible
Date: Thu, 8 Jan 2015 16:26:29 +0000	[thread overview]
Message-ID: <D0D41902.3938%mcooper@hexiscyber.com> (raw)
In-Reply-To: <D0D418B0.3935%mcooper@hexiscyber.com>

I believe there are defects in the code supporting manual configuration of
port link speed and link duplex to values other than auto-negotiate.  The
TESTPMD application from DPDK version 1.8.0 was executed on 2 different
systems having 4x1G NICs with the following Ethernet controllers:

* Intel Corporation 82576 Gigabit Network Connection (rev 01)
* Intel Corporation I350 Gigabit Network Connection (rev 01)

There appears to be two issues in the code:

* "hw->mac.autoneg² is always set to true (1).  The force speed and duplex
code path is not followed.
* "hw->mac.forced_speed_duplex" is never set.  A forced link speed
configuration will always default to 10Mb regardless of whether configured
for 100Mb or 10Mb.  For example, e1000_phy_force_speed_duplex_setup() will
always configure link speed to 10mb since it checks for the following
condition "if (mac->forced_speed_duplex & E1000_ALL_100_SPEED)².

Changes are needed within ³igb_ethdev.c² and ³em_ethdev.c² within
³lib/librte_pmd_e1000².  The switch statements that setup link speed and
link duplex within these files need to manually set "hw->mac.autoneg" and
"hw->mac.forced_speed_duplex" as shown below:

[root@box librte_pmd_e1000]# pwd
/home/marc/dpdk/dpdk-1.8.0/lib/librte_pmd_e1000
[root@box librte_pmd_e1000]# diff  -p igb_ethdev.c.orig igb_ethdev.c
*** igb_ethdev.c.orig	2015-01-08 09:59:52.937215791 -0500
--- igb_ethdev.c	2015-01-08 10:01:44.073730592 -0500
*************** eth_igb_start(struct rte_eth_dev *dev)
*** 871,876 ****
--- 871,878 ----
  			hw->phy.autoneg_advertised = ADVERTISE_10_FULL;
  		else
  			goto error_invalid_config;
+               hw->mac.autoneg = 0;
+               hw->mac.forced_speed_duplex |= hw->phy.autoneg_advertised;
  		break;
  	case ETH_LINK_SPEED_100:
  		if (dev->data->dev_conf.link_duplex == ETH_LINK_AUTONEG_DUPLEX)
*************** eth_igb_start(struct rte_eth_dev *dev)
*** 881,886 ****
--- 883,890 ----
  			hw->phy.autoneg_advertised = ADVERTISE_100_FULL;
  		else
  			goto error_invalid_config;
+               hw->mac.autoneg = 0;
+               hw->mac.forced_speed_duplex |= hw->phy.autoneg_advertised;
  		break;
  	case ETH_LINK_SPEED_1000:
  		if ((dev->data->dev_conf.link_duplex == ETH_LINK_AUTONEG_DUPLEX) ||
*************** eth_igb_start(struct rte_eth_dev *dev)
*** 888,893 ****
--- 892,899 ----
  			hw->phy.autoneg_advertised = ADVERTISE_1000_FULL;
  		else
  			goto error_invalid_config;
+               hw->mac.autoneg = 0;
+               hw->mac.forced_speed_duplex |= hw->phy.autoneg_advertised;
  		break;
  	case ETH_LINK_SPEED_10000:
  	default:
[root@box librte_pmd_e1000]#


After only setting hw->mac.autoneg = 0 in the switch statement cases
described above I experimented with configuring the peer (switch) ports
for 100Mb full duplex.  Within TESTPMD the ports were also configured for
100Mb full duplex using ³port config all speed 100 duplex full².  The
links failed to establish.  I enabled debug statements within
³e1000_phy_force_speed_duplex_setup()² found in
³lib/librte_pmd_e1000/e1000/e1000_phy.c² to display whether 100mb or 10mb
was being forced.  It was observed that 10Mb was being forced when the
link speed was manually configured for 100Mb.  Setting
³hw->mac.force_speed_duplex² as shown above seemed to resolve this issue
and the links came up.
 

Are these known issues?

-Marc

       reply	other threads:[~2015-01-08 16:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <D0D418B0.3935%mcooper@hexiscyber.com>
2015-01-08 16:26 ` Marc E. Cooper [this message]
2015-01-14 12:40   ` Thomas Monjalon

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=D0D41902.3938%mcooper@hexiscyber.com \
    --to=mcooper@hexiscyber.com \
    --cc=dev@dpdk.org \
    /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).