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; >> net...@vger.kernel.org; e1000-devel@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; >>>> net...@vger.kernel.org; e1000-devel@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; >>>>>> net...@vger.kernel.org; e1000-devel@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; net...@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 Sorry. Why can we not disable auto-negotiate on ixgbe NIC ? To be honest, I am interested in it. This is related with hardware or driver?
Thanks a lot. 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 > > ------------------------------------------------------------------------------ _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
