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: <87618083B2453E4A8714035B62D67992504FD8D5@FMSMSX105.amr.corp.intel.com>
Date:	Wed, 30 Dec 2015 16:37:58 +0000
From:	"Tantilov, Emil S" <emil.s.tantilov@...el.com>
To:	zhuyj <zyjzyj2000@...il.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

>-----Original Message-----
>From: zhuyj [mailto:zyjzyj2000@...il.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-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 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:

Is this the scenario you are trying to fix?

>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.

The ixgbe driver does not support disabling auto-negotiation directly.
The only time this is true is when the advertised speed is restricted,
so the above scenario is not possible (you either have autoneg or 
advertised speed set) with the current driver.

Is this example in theory or do you have your interface configured this
way somehow? 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ