Hi, all
About the patch "ixgbe: do not call check_link for ethtool in
ixgbe_get_settings()", I tried to make a similar patch in i40e nic driver.
The patch is as below. This patch is based on the latest linux kernel. I
am not sure that this patch can fix this problem.
Please make tests and let me know the test result.
Hi, Emil
Please comment on the following patch. Thanks a lot.
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 784b165..56a2844 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -489,9 +489,8 @@ static int i40e_get_settings(struct net_device *netdev,
struct i40e_pf *pf = np->vsi->back;
struct i40e_hw *hw = &pf->hw;
struct i40e_link_status *hw_link_info = &hw->phy.link_info;
- bool link_up = hw_link_info->link_info & I40E_AQ_LINK_UP;
- if (link_up)
+ if (netif_carrier_ok(netdev))
i40e_get_settings_link_up(hw, ecmd, netdev, pf);
else
i40e_get_settings_link_down(hw, ecmd, pf);
Zhu Yanjun
On 04/27/2016 06:52 PM, Laszlo Fekete wrote:
Hi,
okay, I think understand your point, what could be the problem.
As I see in 4.5 kernel the bonding patch already there, so I need only
patch i40e driver.
I wanna try it with latest i40e driver (1.5.18), but there are too
much difference from that ixgbe patch so can't really patch with that
and I'm not really familiar with it's source.
Maybe could you give me a patch for i40e_main.c?
Best regards, blackluck
On 2016. April 27. 16:56:25 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
