1. 29 Mar, 2017 37 commits
  2. 28 Mar, 2017 3 commits
    • David S. Miller's avatar
      Merge tag 'mlx5e-failsafe' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · cc628c96
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5e-failsafe 27-03-2017
      
      This series provides a fail-safe mechanism to allow safely re-configuring
      mlx5e netdevice and provides a resiliency against sporadic
      configuration failures.
      
      To enable this we do some refactoring and code reorganizing to allow
      breaking the drivers open/close flows to stages:
            open -> activate -> deactivate -> close.
      
      In addition we need to allow creating fresh HW ring resources
      (mlx5e_channels) with their own "new" set of parameters, while keeping
      the current ones running and active until the new channels are
      successfully created with the new configuration, and only then we can
      safly replace (switch) old channels with new ones.
      
      For that we introduce mlx5e_channels object and an API to manage it:
       - channels = open_channels(new_params):
         open fresh TX/RX channels
       - activate_channels(channels):
         redirect traffic to them and attach them to the netdev
       - deactivate_channes(channels)
         stop traffic and detach from netdev
       - close(channels)
         Free the TX/RX HW resources of those channels
      
      With the above strategy it is straightforward to achieve the desired
      behavior of fail-safe configuration.  In pseudo code:
      
      make_new_config(new_params)
      {
      	old_channels = current_active_channels;
      	new_channels = create_channels(new_params);
      	if (!new_channels)
      		return "Failed, but current channels are still active :)"
      
      	deactivate_channels(old_channels); /* Can't fail */
      	set_hw_new_state();                /* If needed  */
      	activate_channels(new_channels);   /* Can't fail */
      	close_channels(old_channels);
      	current_active_channels = new_channels;
      
              return "SUCCESS";
      }
      
      At the top of this series, we change the following flows to be fail-safe:
      ethtool:
         - ring parameters
         - coalesce parameters
         - tx copy break parameters
         - cqe compressing/moderation mode setting (priv flags)
      ndos:
         - tc setup
         - set features: LRO
         - change mtu
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc628c96
    • David S. Miller's avatar
      Merge branch 'bond-link-status-fixes' · 95ed0edd
      David S. Miller authored
      Mahesh Bandewar says:
      
      ====================
      link-status fixes for mii-monitoring
      
      The mii monitoring is divided into two phases - inspect and commit. The
      inspect phase technically should not make any changes to the state and
      defer it to the commit phase. However detected link state inconsistencies
      on several machines and discovered that it's the result of some
      inconsistent update to link states and assumption that you *always* get
      rtnl-mutex. In reality when trylock() fails to acquire rtnl-mutex, the
      commit phase is postponed until next mii-mon run. At the next round
      because of the state change performed in the previous inspect-run, this
      round does not detect any changes and would skip calling commit phase.
      This would result in an inconsistent state until next link event happens
      (if it ever happens).
      
      During the the commit phase, it's always assumed that speed and duplex
      fetch is always successful, but that's always not the case. However the
      slave state is marked UP irrespective of speed / duplex fetch operation.
      If the speed / duplex fetch operation results in insane values for either
      of these two fields, then keeping internal link state UP is not going to
      provide fruitful results either.
      
      Please see into individual patches for more details.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      95ed0edd
    • Mahesh Bandewar's avatar