From: "Tantilov, Emil S" <emil.s.tantilov@intel.com> To: zhuyj <zyjzyj2000@gmail.com>, "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>, "Brandeburg, Jesse" <jesse.brandeburg@intel.com>, "Nelson, Shannon" <shannon.nelson@intel.com>, "Wyborny, Carolyn" <carolyn.wyborny@intel.com>, "Skidmore, Donald C" <donald.c.skidmore@intel.com>, "Allan, Bruce W" <bruce.w.allan@intel.com>, "Ronciak, John" <john.ronciak@intel.com>, "Williams, Mitch A" <mitch.a.williams@intel.com>, "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "e1000-devel@lists.sourceforge.net" <e1000-devel@lists.sourceforge.net> Cc: "Viswanathan, Ven (Wind River)" <venkat.viswanathan@windriver.com>, "Shteinbock, Boris (Wind River)" <boris.shteinbock@windriver.com>, "Bourg, Vincent (Wind River)" <vincent.bourg@windriver.com> Subject: RE: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex Date: Thu, 24 Dec 2015 05:58:19 +0000 [thread overview] Message-ID: <87618083B2453E4A8714035B62D67992504EC970@FMSMSX105.amr.corp.intel.com> (raw) In-Reply-To: <567B581B.6080608@gmail.com> >-----Original Message----- >From: zhuyj [mailto:zyjzyj2000@gmail.com] >Sent: Wednesday, December 23, 2015 6:28 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@lists.osuosl.org; >netdev@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 1/1] ixgbe: force to synchronize >reporting "link on" and getting speed and duplex > >On 12/23/2015 11:59 PM, Tantilov, Emil S wrote: >>> -----Original Message----- >>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@lists.osuosl.org] >On >>> Behalf Of zyjzyj2000@gmail.com >>> Sent: Tuesday, December 22, 2015 10:47 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@lists.osuosl.org; netdev@vger.kernel.org; e1000- >>> devel@lists.sourceforge.net >>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); >Bourg, >>> Vincent (Wind River) >>> Subject: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize >>> reporting "link on" and getting speed and duplex >>> >>> From: Zhu Yanjun <zyjzyj2000@gmail.com> >>> >>> In X540 NIC, there is a time span between reporting "link on" and >>> getting the speed and duplex. To a bonding driver in 802.3ad mode, >>> this time span will make it not work well if the time span is big >>> enough. The big time span will make bonding driver change the state of >>> the slave device to up while the speed and duplex of the slave device >>> can not be gotten. Later the bonding driver will not have change to >>> get the speed and duplex of the slave device. The speed and duplex of >>> the slave device are important to a bonding driver in 802.3ad mode. >>> >>> To 82599_SFP NIC and other kinds of NICs, this problem does >>> not exist. As such, it is necessary for X540 to report"link on" when >>> the link speed is not IXGBE_LINK_SPEED_UNKNOWN. >>> >>> Signed-off-by: Zhu Yanjun <zyjzyj2000@gmail.com> >>> --- >>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +++++++++++++++- >>> 1 file changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c >>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c >>> index aed8d02..cb9d310 100644 >>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c >>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c >>> @@ -6479,7 +6479,21 @@ static void ixgbe_watchdog_link_is_up(struct >>> ixgbe_adapter *adapter) >>> (flow_rx ? "RX" : >>> (flow_tx ? "TX" : "None")))); >>> >>> - netif_carrier_on(netdev); >>> + /* >>> + * In X540 NIC, there is a time span between reporting "link on" >>> + * and getting the speed and duplex. To a bonding driver in 802.3ad >>> + * mode, this time span will make it not work well if the time span >>> + * is big enough. To 82599_SFP NIC and other kinds of NICs, this >>> + * problem does not exist. As such, it is better for X540 to report >>> + * "link on" when the link speed is not IXGBE_LINK_SPEED_UNKNOWN. >>> + */ >>> + if ((hw->mac.type == ixgbe_mac_X540) && >>> + (link_speed != IXGBE_LINK_SPEED_UNKNOWN)) { >>> + netif_carrier_on(netdev); >>> + } else { >>> + netif_carrier_on(netdev); >>> + } >>> + >>> ixgbe_check_vf_rate_limit(adapter); >>> >>> /* enable transmits */ >>> -- >>> 1.7.9.5 >> NAK >> >> I have already submitted a patch that will address the issue with bonding >reporting >> unknown speed (in /proc/bonding/bondX) after the link is established due >to link flaps: >> http://patchwork.ozlabs.org/patch/552485/ >> >> The bonding driver gets the speed from ethtool and this is where the >reporting needs >> to be fixed. The issue is that the bonding driver polls for >netif_carrier_ok() at a >> certain rate and as such will not be able to detect rapid link changes. >Thanks for your reply. The root cause is different from my problem. My >problem is that >"link up" is prior to "speed and duplex". That is, the physical NIC >reports "link up" while The "link up" event is a result of an LSC interrupt, the speed is determined as result of that interrupt by checking the LINKS register. If the LINKS register reports link as unknown then that is the actual state of the PHY - meaning the device is re-negotiating the speed for some reason. >the speed is unknown at the same time. We can run "ethtool ethx" to >confirm it. Prior to my patch the ethtool call will read the LINKS register which can show speed as unknown due to a link flap (for example). You are seeing the momentary state of the device. If you are still seeing the bond reporting "unknown" speed after the patch I pointed out please file a bug either through e1000.sf.net or via Intel support and provide detailed information about the bonding setup, the type of the link partner (switch model etc) and full dmesg from the failed scenario along with the output from /proc/bonding/bond0 Thanks, Emil
WARNING: multiple messages have this Message-ID (diff)
From: Tantilov, Emil S <emil.s.tantilov@intel.com> To: intel-wired-lan@osuosl.org Subject: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex Date: Thu, 24 Dec 2015 05:58:19 +0000 [thread overview] Message-ID: <87618083B2453E4A8714035B62D67992504EC970@FMSMSX105.amr.corp.intel.com> (raw) In-Reply-To: <567B581B.6080608@gmail.com> >-----Original Message----- >From: zhuyj [mailto:zyjzyj2000 at gmail.com] >Sent: Wednesday, December 23, 2015 6:28 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 at lists.osuosl.org; >netdev at vger.kernel.org; e1000-devel at lists.sourceforge.net >Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); Bourg, >Vincent (Wind River) >Subject: Re: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize >reporting "link on" and getting speed and duplex > >On 12/23/2015 11:59 PM, Tantilov, Emil S wrote: >>> -----Original Message----- >>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] >On >>> Behalf Of zyjzyj2000 at gmail.com >>> Sent: Tuesday, December 22, 2015 10:47 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 at lists.osuosl.org; netdev at vger.kernel.org; e1000- >>> devel at lists.sourceforge.net >>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); >Bourg, >>> Vincent (Wind River) >>> Subject: [Intel-wired-lan] [PATCH 1/1] ixgbe: force to synchronize >>> reporting "link on" and getting speed and duplex >>> >>> From: Zhu Yanjun <zyjzyj2000@gmail.com> >>> >>> In X540 NIC, there is a time span between reporting "link on" and >>> getting the speed and duplex. To a bonding driver in 802.3ad mode, >>> this time span will make it not work well if the time span is big >>> enough. The big time span will make bonding driver change the state of >>> the slave device to up while the speed and duplex of the slave device >>> can not be gotten. Later the bonding driver will not have change to >>> get the speed and duplex of the slave device. The speed and duplex of >>> the slave device are important to a bonding driver in 802.3ad mode. >>> >>> To 82599_SFP NIC and other kinds of NICs, this problem does >>> not exist. As such, it is necessary for X540 to report"link on" when >>> the link speed is not IXGBE_LINK_SPEED_UNKNOWN. >>> >>> Signed-off-by: Zhu Yanjun <zyjzyj2000@gmail.com> >>> --- >>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +++++++++++++++- >>> 1 file changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c >>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c >>> index aed8d02..cb9d310 100644 >>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c >>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c >>> @@ -6479,7 +6479,21 @@ static void ixgbe_watchdog_link_is_up(struct >>> ixgbe_adapter *adapter) >>> (flow_rx ? "RX" : >>> (flow_tx ? "TX" : "None")))); >>> >>> - netif_carrier_on(netdev); >>> + /* >>> + * In X540 NIC, there is a time span between reporting "link on" >>> + * and getting the speed and duplex. To a bonding driver in 802.3ad >>> + * mode, this time span will make it not work well if the time span >>> + * is big enough. To 82599_SFP NIC and other kinds of NICs, this >>> + * problem does not exist. As such, it is better for X540 to report >>> + * "link on" when the link speed is not IXGBE_LINK_SPEED_UNKNOWN. >>> + */ >>> + if ((hw->mac.type == ixgbe_mac_X540) && >>> + (link_speed != IXGBE_LINK_SPEED_UNKNOWN)) { >>> + netif_carrier_on(netdev); >>> + } else { >>> + netif_carrier_on(netdev); >>> + } >>> + >>> ixgbe_check_vf_rate_limit(adapter); >>> >>> /* enable transmits */ >>> -- >>> 1.7.9.5 >> NAK >> >> I have already submitted a patch that will address the issue with bonding >reporting >> unknown speed (in /proc/bonding/bondX) after the link is established due >to link flaps: >> http://patchwork.ozlabs.org/patch/552485/ >> >> The bonding driver gets the speed from ethtool and this is where the >reporting needs >> to be fixed. The issue is that the bonding driver polls for >netif_carrier_ok() at a >> certain rate and as such will not be able to detect rapid link changes. >Thanks for your reply. The root cause is different from my problem. My >problem is that >"link up" is prior to "speed and duplex". That is, the physical NIC >reports "link up" while The "link up" event is a result of an LSC interrupt, the speed is determined as result of that interrupt by checking the LINKS register. If the LINKS register reports link as unknown then that is the actual state of the PHY - meaning the device is re-negotiating the speed for some reason. >the speed is unknown at the same time. We can run "ethtool ethx" to >confirm it. Prior to my patch the ethtool call will read the LINKS register which can show speed as unknown due to a link flap (for example). You are seeing the momentary state of the device. If you are still seeing the bond reporting "unknown" speed after the patch I pointed out please file a bug either through e1000.sf.net or via Intel support and provide detailed information about the bonding setup, the type of the link partner (switch model etc) and full dmesg from the failed scenario along with the output from /proc/bonding/bond0 Thanks, Emil
next prev parent reply other threads:[~2015-12-24 5:58 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-23 6:46 [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex zyjzyj2000 2015-12-23 6:46 ` [Intel-wired-lan] " zyjzyj2000 2015-12-23 10:54 ` Jeff Kirsher 2015-12-23 10:54 ` [Intel-wired-lan] " Jeff Kirsher 2015-12-24 3:12 ` [V2 PATCH 1/1] ixgbe: force to synchronize reporting "link on" and zyjzyj2000 2015-12-24 3:12 ` [Intel-wired-lan] " zyjzyj2000 2015-12-24 3:12 ` [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed zyjzyj2000 2015-12-24 3:12 ` [Intel-wired-lan] " zyjzyj2000 2015-12-24 5:10 ` [V2 PATCH 1/1] ixgbe: force to synchronize reporting "link on" and zhuyj 2015-12-24 5:10 ` [Intel-wired-lan] " zhuyj 2015-12-24 6:17 ` Tantilov, Emil S 2015-12-24 6:17 ` Tantilov, Emil S 2015-12-29 2:32 ` [PATCH V3] ixgbe: force to synchronize link_up and speed as a slave zyjzyj2000 2015-12-29 2:32 ` [Intel-wired-lan] " zyjzyj2000 2015-12-29 2:32 ` [PATCH 1/2] ixgbe: force to synchronize reporting "link on" and getting speed zyjzyj2000 2015-12-29 2:32 ` [Intel-wired-lan] " zyjzyj2000 2015-12-29 2:32 ` [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed zyjzyj2000 2015-12-29 2:32 ` [Intel-wired-lan] " zyjzyj2000 2015-12-29 16:18 ` Tantilov, Emil S 2015-12-29 16:18 ` Tantilov, Emil S 2015-12-29 19:17 ` Rustad, Mark D 2015-12-29 19:17 ` Rustad, Mark D 2015-12-30 3:06 ` zhuyj 2015-12-30 3:06 ` zhuyj 2015-12-30 9:16 ` [PATCH V4] ixgbe: synchronize the link_speed and link_up of a slave interface zyjzyj2000 2015-12-30 9:16 ` [Intel-wired-lan] " zyjzyj2000 2015-12-30 9:16 ` [PATCH 1/3] ixgbe: force to synchronize reporting "link on" and getting speed zyjzyj2000 2015-12-30 9:16 ` [Intel-wired-lan] " zyjzyj2000 2015-12-30 9:16 ` [PATCH 2/3] ixgbe: restrict synchronization of link_up and speed zyjzyj2000 2015-12-30 9:16 ` [Intel-wired-lan] " zyjzyj2000 2015-12-30 9:16 ` [PATCH 3/3] ixgbe: synchronize the link_speed and link_up of a slave interface zyjzyj2000 2015-12-30 9:16 ` [Intel-wired-lan] " zyjzyj2000 2015-12-30 19:02 ` Rustad, Mark D 2015-12-30 19:02 ` [Intel-wired-lan] " Rustad, Mark D 2015-12-31 5:04 ` [PATCH V5] ixgbe: synchronize link_up and link_speed of a slave zyjzyj2000 2015-12-31 5:04 ` [Intel-wired-lan] " zyjzyj2000 2015-12-31 5:04 ` [PATCH 1/1] ixgbe: synchronize link_up and link_speed of a slave interface zyjzyj2000 2015-12-31 5:04 ` [Intel-wired-lan] " zyjzyj2000 2015-12-31 5:37 ` Jeff Kirsher 2015-12-31 5:37 ` [Intel-wired-lan] " Jeff Kirsher 2015-12-31 7:11 ` [PATCH V6] ixgbe: synchronize link_up and link_speed of a slave zyjzyj2000 2015-12-31 7:11 ` [Intel-wired-lan] " zyjzyj2000 2015-12-31 7:11 ` [PATCH V6 1/1] ixgbe: synchronize link_up and link_speed of a slave interface zyjzyj2000 2015-12-31 7:11 ` [Intel-wired-lan] " zyjzyj2000 2015-12-31 5:17 ` [PATCH V5] ixgbe: synchronize link_up and link_speed of a slave Jeff Kirsher 2015-12-31 5:17 ` [Intel-wired-lan] " Jeff Kirsher 2015-12-31 5:24 ` zhuyj 2015-12-31 5:24 ` [Intel-wired-lan] " zhuyj 2015-12-30 2:49 ` [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed zhuyj 2015-12-30 2:49 ` zhuyj 2015-12-30 6:55 ` Tantilov, Emil S 2015-12-30 6:55 ` Tantilov, Emil S 2015-12-30 8:20 ` zhuyj 2015-12-30 8:20 ` zhuyj 2015-12-30 16:37 ` Tantilov, Emil S 2015-12-30 16:37 ` Tantilov, Emil S 2016-01-06 5:41 ` zhuyj 2016-01-06 5:41 ` zhuyj 2016-01-06 15:30 ` Tantilov, Emil S 2016-01-06 15:30 ` Tantilov, Emil S 2016-01-07 2:08 ` zhuyj 2016-01-07 2:08 ` zhuyj 2016-01-07 2:38 ` zhuyj 2016-01-07 2:38 ` zhuyj 2015-12-23 12:17 ` [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex Sergei Shtylyov 2015-12-23 12:17 ` [Intel-wired-lan] " Sergei Shtylyov 2015-12-23 15:59 ` Tantilov, Emil S 2015-12-23 15:59 ` Tantilov, Emil S 2015-12-23 18:09 ` [E1000-devel] " Stephen Hemminger 2015-12-23 18:09 ` [Intel-wired-lan] [E1000-devel] " Stephen Hemminger 2015-12-24 2:27 ` [Intel-wired-lan] " zhuyj 2015-12-24 2:27 ` zhuyj 2015-12-24 5:58 ` Tantilov, Emil S [this message] 2015-12-24 5:58 ` Tantilov, Emil S 2015-12-24 6:24 ` zhuyj 2015-12-24 6:24 ` zhuyj 2015-12-24 14:52 ` Tantilov, Emil S 2015-12-24 14:52 ` Tantilov, Emil S
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87618083B2453E4A8714035B62D67992504EC970@FMSMSX105.amr.corp.intel.com \ --to=emil.s.tantilov@intel.com \ --cc=boris.shteinbock@windriver.com \ --cc=bruce.w.allan@intel.com \ --cc=carolyn.wyborny@intel.com \ --cc=donald.c.skidmore@intel.com \ --cc=e1000-devel@lists.sourceforge.net \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=jeffrey.t.kirsher@intel.com \ --cc=jesse.brandeburg@intel.com \ --cc=john.ronciak@intel.com \ --cc=mitch.a.williams@intel.com \ --cc=netdev@vger.kernel.org \ --cc=shannon.nelson@intel.com \ --cc=venkat.viswanathan@windriver.com \ --cc=vincent.bourg@windriver.com \ --cc=zyjzyj2000@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.