On 12/30/2015 02:55 PM, Tantilov, Emil S wrote:
-----Original Message-----
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Tuesday, December 29, 2015 6:49 PM
To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
John; Williams, Mitch A; intel-wired-...@lists.osuosl.org;
netdev@vger.kernel.org; e1000-de...@lists.sourceforge.net
Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); Bourg,
Vincent (Wind River)
Subject: Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization
of link_up and speed
On 12/30/2015 12:18 AM, Tantilov, Emil S wrote:
-----Original Message-----
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org]
On
Behalf Of zyjzyj2...@gmail.com
Sent: Monday, December 28, 2015 6:32 PM
To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak, John; Williams,
Mitch
A; intel-wired-...@lists.osuosl.org; netdev@vger.kernel.org; e1000-
de...@lists.sourceforge.net
Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
Bourg,
Vincent (Wind River)
Subject: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization
of
link_up and speed
From: Zhu Yanjun <yanjun....@windriver.com>
When the X540 NIC acts as a slave of some virtual NICs, it is very
important to synchronize link_up and link_speed, such as a bonding
driver in 802.3ad mode. When X540 NIC acts as an independent interface,
it is not necessary to synchronize link_up and link_speed. That is,
the time span between link_up and link_speed is acceptable.
What exactly do you mean by "time span between link_up and link_speed"?
In the previous mail, I show you some ethtool logs. In these logs, there
is some
time with NIC up while speed is unknown. I think this "some time" is
time span between
link_up and link_speed. Please see the previous mail for details.
Was this when reporting the link state from check_link() (reading the LINKS
register) or reporting the adapter->link_speed?
Where is it you think the de-synchronization occurs?
When a NIC interface acts as a slave, a flag "IFF_SLAVE" is set in
netdevice struct.
Before we enter this function, we check IFF_SLAVE flag. If this flag is
set, we continue to check
link_speed. If not, this function is executed whether this link_speed is
unknown or not.
I can already see this in your patch. I was asking about the reason why your
change is needed.
an extreme example, let us assume this scenario:
An ixgbe NIC directly connects to another NIC (let us call it NIC-a).
And auto-negotiate is off while no static speed is set in the 2 NICs.
These 2 NICs acts as 2 independent interfaces. As such, at this time,
there is no speed in the both 2 NICs. That is, link_speed is unknown.
When the user run "ifconfig or ethtool", NIC-a will show "Link detected:
yes" while ixgbe NIC will show "Link detected: no" if the flag IFF_SLAVE
is not set.
NIC-a stands for most NIC, such as e1000, e1000e and so on.
Best Regards!
Zhu Yanjun
Signed-off-by: Zhu Yanjun <yanjun....@windriver.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index ace21b9..1bb6056 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6436,8 +6436,15 @@ static void ixgbe_watchdog_link_is_up(struct
ixgbe_adapter *adapter)
* time. To X540 NIC, there is a time span between link_up and
* link_speed. As such, only continue if link_up and link_speed are
* ready to X540 NIC.
+ * The time span between link_up and link_speed is very important
+ * when the X540 NIC acts as a slave in some virtual NICs, such as
+ * a bonding driver in 802.3ad mode. When X540 NIC acts as an
+ * independent interface, it is not necessary to synchronize link_up
+ * and link_speed.
+ * In the end, not continue if (X540 NIC && SLAVE && link_speed
UNKNOWN)
This is a patch on top of your previous patch which I don't think was
applied,
so this is not going to apply cleanly.
*/
- if (hw->mac.type == ixgbe_mac_X540)
+ if ((hw->mac.type == ixgbe_mac_X540) &&
+ (netdev->flags & IFF_SLAVE))
if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
return;
If you were to enter ixgbe_watchdog_link_is_up() with unknown speed, then
I would
assume that you also have a dmesg that shows:
"NIC Link is Up unknown speed"
by the interface you use in the bond?
Sure. There is a dmesg log from the customer.
"
...
2015-10-05T06:14:34.350 controller-0 kernel: info bonding: bond0: link
status definitely up for interface eth0, 0 Mbps full duplex.
This message is from the bonding driver not from ixgbe.
In your patch you are adding a check for unknown link to
ixgbe_watchdog_link_is_up()
if that condition was true then you should also see "unknown link" being
reported by ixgbe.
Thanks,
Emil
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
