netdev - Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <568393C6.1060105@gmail.com>
Date:	Wed, 30 Dec 2015 16:20:22 +0800
From:	zhuyj <zyjzyj2000@...il.com>
To:	"Tantilov, Emil S" <emil.s.tantilov@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Nelson, Shannon" <shannon.nelson@...el.com>,
	"Wyborny, Carolyn" <carolyn.wyborny@...el.com>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"Williams, Mitch A" <mitch.a.williams@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Cc:	"Viswanathan, Ven (Wind River)" <venkat.viswanathan@...driver.com>,
	"Shteinbock, Boris (Wind River)" <boris.shteinbock@...driver.com>,
	"Bourg, Vincent (Wind River)" <vincent.bourg@...driver.com>
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:zyjzyj2000@...il.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-lan@...ts.osuosl.org;
>> netdev@...r.kernel.org; e1000-devel@...ts.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-bounces@...ts.osuosl.org]
>> On
>>>> Behalf Of zyjzyj2000@...il.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-lan@...ts.osuosl.org; netdev@...r.kernel.org; e1000-
>>>> devel@...ts.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.zhu@...driver.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.zhu@...driver.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html