1. 27 Aug, 2013 1 commit
  2. 19 Apr, 2013 3 commits
  3. 07 Mar, 2013 1 commit
  4. 25 Feb, 2013 2 commits
    • Neil Horman's avatar
      vmxnet3: fix ethtool ring buffer size setting · 48412a7e
      Neil Horman authored
      
      
      Noticed that vmxnet3's get_ringparam function was returning the summation of all
      ring buffers on a NIC, rather than just the size of any one ring.  This causes
      problems when a vmxnet3 instance has multiple queues, as ethtool, when setting
      ring parameters, first gets the current ring parameters to set the existing
      values in the set_ringparm commannd.  The result is, that unless both rx and tx
      ring sizes are set in a single operation, which ever ring is not set will
      silently have its ring count multiplied by the number of queues on the NIC until
      it reaches a driver defined maxiumum value.
      
      Fix it by not multiplying the rx and tx ring sizes by the number of queues in
      the system, like every other driver.  Tested by myself successfully.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Shreyas Bhatewara <sbhatewara@vmware.com>
      CC: "VMware, Inc." <pv-drivers@vmware.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48412a7e
    • stephen hemminger's avatar
  5. 29 Jan, 2013 1 commit
    • Neil Horman's avatar
      vmxnet3: set carrier state properly on probe · 6cdd20c3
      Neil Horman authored
      
      
      vmxnet3 fails to set netif_carrier_off on probe, meaning that when an interface
      is opened the __LINK_STATE_NOCARRIER bit is already cleared, and so
      /sys/class/net/<ifname>/operstate remains in the unknown state.  Correct this by
      setting netif_carrier_off on probe, like other drivers do.
      
      Also, while we're at it, lets remove the netif_carrier_ok checks from the
      link_state_update function, as that check is atomically contained within the
      netif_carrier_[on|off] functions anyway
      
      Tested successfully by myself
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: "VMware, Inc." <pv-drivers@vmware.com>
      CC: Ben Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6cdd20c3
  6. 16 Jan, 2013 10 commits
  7. 07 Jan, 2013 1 commit
  8. 03 Dec, 2012 1 commit
  9. 15 Nov, 2012 1 commit
  10. 09 Nov, 2012 1 commit
  11. 03 Nov, 2012 1 commit
  12. 15 Aug, 2012 1 commit
  13. 06 Jun, 2012 1 commit
  14. 05 Mar, 2012 1 commit
  15. 02 Mar, 2012 1 commit
  16. 19 Feb, 2012 1 commit
    • Neil Horman's avatar
      vmxnet3: cap copy length at size of skb to prevent dropped frames on tx · b203262d
      Neil Horman authored
      I was recently shown that vmxnet3 devices on transmit, will drop very small udp
      frames consistently.  This is due to a regression introduced by commit
      39d4a96f
      
      .  This commit attempts to introduce an
      optimization to the tx path, indicating that the underlying hardware behaves
      optimally when at least 54 bytes of header data are available for direct access.
      This causes problems however, if the entire frame is less than 54 bytes long.
      The subsequent pskb_may_pull in vmxnet3_parse_and_copy_hdr fails, causing an
      error return code, which leads to vmxnet3_tq_xmit dropping the frame.
      
      Fix it by placing a cap on the copy length.  For frames longer than 54 bytes, we
      do the pull as we normally would.  If the frame is shorter than that, copy the
      whole frame, but no more.  This ensures that we still get the optimization for
      qualifying frames, but don't do any damange for frames that are too short.
      
      Also, since I'm unable to do this, it wuold be great if vmware could follow up
      this patch with some additional code commentary as to why 54 bytes is an optimal
      pull length for a virtual NIC driver.  The comment that introduced this was
      vague on that.  Thanks!
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: default avatarMax Matveev <mmatveev@redhat.com>
      CC: Max Matveev <mmatveev@redhat.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Shreyas Bhatewara <sbhatewara@vmware.com>
      CC: "VMware, Inc." <pv-drivers@vmware.com>
      Signed-off-by: default avatarShreyas N Bhatewara <sbhatewara@vmware.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b203262d
  17. 01 Feb, 2012 1 commit
  18. 31 Jan, 2012 2 commits
  19. 25 Jan, 2012 1 commit
  20. 05 Jan, 2012 1 commit
  21. 16 Dec, 2011 2 commits
  22. 09 Dec, 2011 1 commit
  23. 22 Nov, 2011 1 commit
  24. 16 Nov, 2011 1 commit
  25. 31 Oct, 2011 1 commit
  26. 19 Oct, 2011 1 commit