Hi, Please let me know "i40e: synchronize link_up and link_speed of a slave interface" work or not.
I am making a new patch for you. Best Regards! Zhu Yanjun On 04/27/2016 04:56 PM, zhuyj wrote: > Hi, > > The patches are too many. Based on the latest linux kernel, I modified > the patch in the link:http://patchwork.ozlabs.org/patch/561848/ > > If the root cause is correct, the following patch should fix this > problem. This patch is based on the analysis. > And it is only for test. Please let me know the test result. > > Thanks a lot. > Zhu Yanjun > > From 57602f5ceafb2bfddfe222ea63ff7444179d8ac9 Mon Sep 17 00:00:00 2001 > From: Zhu Yanjun <zyjzyj2...@gmail.com> > Date: Wed, 27 Apr 2016 01:51:51 -0700 > Subject: [PATCH 1/1] i40e: synchronize link_up and link_speed of a slave > interface > > Similar to ixgbe nic, i40e nic needs the similar logic to handle > the synchronization of link_up and link_speed of a slave interface. > To all the slave interfaces, the link_speed and link_up should be > synchronized since the time span between link_up and link_speed > will make some virtual NICs not work well, such as a bonding driver > in 802.3ad mode. > > Signed-off-by: Zhu Yanjun <zyjzyj2...@gmail.com> > --- > drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c > b/drivers/net/ethernet/intel/i40e/i40e_main.c > index 3449129..6bb178c 100644 > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c > @@ -6133,6 +6133,10 @@ static void i40e_link_event(struct i40e_pf *pf) > new_link == netif_carrier_ok(vsi->netdev))) > return; > > + if ((vsi->netdev->flags & IFF_SLAVE) && > + (new_link_speed == 0)) > + return; > + > if (!test_bit(__I40E_DOWN, &vsi->state)) > i40e_print_link_message(vsi, new_link); > > > On 04/27/2016 04:10 PM, zhuyj wrote: >> On 04/27/2016 03:47 PM, Laszlo Fekete wrote: >>> >>> [ 211.955239] i40e 0000:04:00.0 enp4s0f0: speed changed to 0 for >>> port enp4s0f0 >>> >>> [ 211.956912] bond0: link status up again after 0 ms for interface >>> enp4s0f0 >>> >> Hi, >> >> I can not reproduce your problem because I have no i40e device. >> But from the following dmesg message. >> >> " >> ... >> [ 211.955239] i40e 0000:04:00.0 enp4s0f0: speed changed to 0 for >> port enp4s0f0 >> [ 211.956912] bond0: link status up again after 0 ms for interface >> enp4s0f0 >> ... >> " >> I think the i40e nic is up while the speed remain 0. IMHO, your >> problem is similar to mine. >> I think this problem only occurs with 802.3ad. Am I correct? >> >> If so, I think the latest bonding driver should fix this problem. >> You can try these patches: >> >> 1. >> commit 266b495f11d6706018f66250cb02a788ff2490d7 >> Author: Jay Vosburgh <jay.vosbu...@canonical.com> >> Date: Mon Feb 8 12:10:02 2016 -0800 >> >> bonding: don't use stale speed and duplex information >> >> There is presently a race condition between the bonding periodic >> link monitor and the updating of a slave's speed and duplex. The >> former >> occurs on a periodic basis, and the latter in response to a driver's >> calling of netif_carrier_on. >> >> It is possible for the periodic monitor to run between the >> driver call of netif_carrier_on and the receipt of the NETDEV_CHANGE >> event that causes bonding to update the slave's speed and >> duplex. This >> manifests most notably as a report that a slave is up and "0 Mbps >> full >> duplex" after enslavement, but in principle could report an >> incorrect >> speed and duplex after any link up event if the device comes up >> with a >> different speed or duplex. This affects the 802.3ad aggregator >> selection, as the speed and duplex are selection criteria. >> >> This is fixed by updating the speed and duplex in the periodic >> monitor, prior to using that information. >> >> This was done historically in bonding, but the call to >> bond_update_speed_duplex was removed in commit 876254ae2758 >> ("bonding: >> don't call update_speed_duplex() under spinlocks"), as it might >> sleep >> under lock. Later, the locking was changed to only hold RTNL, >> and so >> after commit 876254ae2758 ("bonding: don't call >> update_speed_duplex() >> under spinlocks") this call is again safe. >> >> Tested-by: "Tantilov, Emil S" <emil.s.tanti...@intel.com> >> Cc: Veaceslav Falico <vfal...@gmail.com> >> Cc: dingtianhong <dingtianh...@huawei.com> >> Fixes: 876254ae2758 ("bonding: don't call update_speed_duplex() >> under spinlocks") >> Signed-off-by: Jay Vosburgh <jay.vosbu...@canonical.com> >> Acked-by: Ding Tianhong <dingtianh...@huawei.com> >> Signed-off-by: David S. Miller <da...@davemloft.net> >> >> 2. the patches for ixgbe drivers. You can use them in i40e driver. >> >> commit 0e4d422f5f7249324ac8d1b8e12772e530787a66 >> Author: Emil Tantilov <emil.s.tanti...@intel.com> >> Date: Thu Dec 3 15:20:06 2015 -0800 >> >> ixgbe: do not call check_link for ethtool in ixgbe_get_settings() >> >> In ixgbe_get_settings() the link status and speed of the interface >> are determined based on a read from the LINKS register via the call >> to mac.ops.check.link(). This can cause issues where external >> drivers >> may end up with unknown speed when calling ethtool_get_setings(). >> >> Instead of calling the mac.ops.check_link() we can report the speed >> from the adapter structure which is populated by the driver. >> >> Signed-off-by: Emil Tantilov <emil.s.tanti...@intel.com> >> Tested-by: Phil Schmitt <phillip.j.schm...@intel.com> >> Signed-off-by: Jeff Kirsher <jeffrey.t.kirs...@intel.com> >> >> >> 3. The patch in the link is applied for ixgbe nic driver. You can try >> it in i40e nic. >> http://patchwork.ozlabs.org/patch/561848/ >> >> All the patches are applied in bonding and i40e. I think this problem >> should be resolved. >> >> In the end, add emil.s.tanti...@intel.com and >> jay.vosbu...@canonical.com. >> >> Please let me know the test result. >> >> Thanks a lot. >> Zhu Yanjun >> > ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ 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
