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