1. 22 Mar, 2018 2 commits
  2. 19 Mar, 2018 1 commit
  3. 18 Mar, 2018 1 commit
  4. 14 Mar, 2018 3 commits
  5. 13 Mar, 2018 1 commit
  6. 09 Mar, 2018 4 commits
  7. 08 Mar, 2018 9 commits
  8. 07 Mar, 2018 2 commits
    • David Johnson's avatar
      On Linux clients, fix eth speed via ethtool; fallback to autoneg on failure. · 9337f7d4
      David Johnson authored
      This is now our strategy for everything except a speed of 0 (which means
      autonegotiate); and a speed of 1 Gbps (which requires autoneg anyway).
      
      Not all cards allow ethtool to "fix" speeds; but some (still) require
      it.  For instance, this commit when applied to an Intel X710 card that
      should be at 10Gbps has no affect; apparently ethtool cannot fix speeds
      for that card and/or driver.  On the other hand, Mellanox 10/25Gbps
      cards sometimes require the speed to be manually set (i.e., if they are
      directly connected to each other via a layer1 switch).  Even on those
      cards, it's not really setting it; it's just hinting to the autoneg
      process which speed you really want (and I'd guess that is true for all
      modern high-speed Ethernet chips).
      
      Anyway, we don't know when to force the speed set/suggest or not unless
      we track more data at the server side, so the current strategy is to
      always attempt to set/suggest the speed we want, and fallback to setting
      autoneg if we fail.  Note that sometimes ethtool returns successfully
      even if settings fail (I'm looking at you, Intel X710), so this strategy
      is already sort of doomed to failure (but it hasn't made anything not
      work!).  If it causes problems for any cards/drivers/speed combinations,
      we'll revisit this, obviously.
      9337f7d4
    • Robert Ricci's avatar
      4b0dbcc2
  9. 06 Mar, 2018 5 commits
  10. 02 Mar, 2018 4 commits
  11. 01 Mar, 2018 7 commits
  12. 28 Feb, 2018 1 commit
    • Mike Hibler's avatar
      Prevent a new VLAN from getting put into every existing trunk port. · 4a1d42b7
      Mike Hibler authored
      This is the flip-side of something the Mellanox module already handled:
      putting a port in trunk mode and having it inherit all existing VLANs.
      
      The only sure fire way to do this was to make sure, after creating a new
      VLAN, that every existing trunk port does not include the VLAN. If it
      does, we remove it.
      4a1d42b7