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