On 01/06/2016 11:30 PM, Tantilov, Emil S wrote:
-----Original Message-----
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Tuesday, January 05, 2016 9:42 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/31/2015 12:37 AM, Tantilov, Emil S wrote:
-----Original Message-----
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Wednesday, December 30, 2015 12:20 AM
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 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:
Is this the scenario you are trying to fix?
Sure. If IFF_SLAVE is checked, this scenario will not happen.
I already explained why this is not a valid scenario, but if you were able
to set it up somehow I'd like to know how you did it
If it is not a valid scenario, maybe there is something wrong with NIC
driver/hardware.
We should pay attention to it.
Zhu Yanjun
If we are to enter ixgbe_watchdog_link_is_up() with unknown link this would
be an issue regardless of whether the interface is a part of a bond or not,
but you haven't provided any proof that this is the case. Do you have a
dmesg log that shows ixgbe reporting unknown speed?
Was your patch tested by the customer that reported this issue?
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
