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
| ||
|
Date: Wed, 30 Dec 2015 10:49:16 +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 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. > 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. > >> 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. ... " Thanks a lot. Zhu Yanjun > > 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