1. 25 1月, 2020 1 次提交
    • H
      hv_netvsc: Add XDP support · 351e1581
      Haiyang Zhang 提交于
      This patch adds support of XDP in native mode for hv_netvsc driver, and
      transparently sets the XDP program on the associated VF NIC as well.
      
      Setting / unsetting XDP program on synthetic NIC (netvsc) propagates to
      VF NIC automatically. Setting / unsetting XDP program on VF NIC directly
      is not recommended, also not propagated to synthetic NIC, and may be
      overwritten by setting of synthetic NIC.
      
      The Azure/Hyper-V synthetic NIC receive buffer doesn't provide headroom
      for XDP. We thought about re-use the RNDIS header space, but it's too
      small. So we decided to copy the packets to a page buffer for XDP. And,
      most of our VMs on Azure have Accelerated  Network (SRIOV) enabled, so
      most of the packets run on VF NIC. The synthetic NIC is considered as a
      fallback data-path. So the data copy on netvsc won't impact performance
      significantly.
      
      XDP program cannot run with LRO (RSC) enabled, so you need to disable LRO
      before running XDP:
              ethtool -K eth0 lro off
      
      XDP actions not yet supported:
              XDP_REDIRECT
      Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      351e1581
  2. 21 12月, 2019 1 次提交
  3. 24 11月, 2019 1 次提交
  4. 22 11月, 2019 2 次提交
  5. 06 11月, 2019 1 次提交
  6. 07 9月, 2019 1 次提交
  7. 31 5月, 2019 1 次提交
  8. 30 3月, 2019 1 次提交
  9. 24 1月, 2019 2 次提交
  10. 23 9月, 2018 2 次提交
  11. 31 7月, 2018 1 次提交
    • Y
      hv_netvsc: Add per-cpu ethtool stats for netvsc · 6ae74671
      Yidong Ren 提交于
      This patch implements following ethtool stats fields for netvsc:
      cpu<n>_tx/rx_packets/bytes
      cpu<n>_vf_tx/rx_packets/bytes
      
      Corresponding per-cpu counters already exist in current code. Exposing
      these counters will help troubleshooting performance issues.
      
      for_each_present_cpu() was used instead of for_each_possible_cpu().
      for_each_possible_cpu() would create very long and useless output.
      It is still being used for internal buffer, but not for ethtool
      output.
      
      There could be an overflow if cpu was added between ethtool
      call netvsc_get_sset_count() and netvsc_get_ethtool_stats() and
      netvsc_get_strings(). (still safe if cpu was removed)
      ethtool makes these three function calls separately.
      As long as we use ethtool, I can't see any clean solution.
      
      Currently and in foreseeable short term, Hyper-V doesn't support
      cpu hot-plug. Plus, ethtool is for admin use. Unlikely the admin
      would perform such combo operations.
      
      Changes in v2:
        - Remove cpp style comment
        - Resubmit after freeze
      
      Changes in v3:
        - Reimplemented with kvmalloc instead of alloc_percpu
      
      Changes in v4:
        - Fixed inconsistent array size
        - Use kvmalloc_array instead of kvmalloc
      Signed-off-by: NYidong Ren <yidren@microsoft.com>
      Reviewed-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ae74671
  12. 30 6月, 2018 1 次提交
  13. 15 6月, 2018 1 次提交
  14. 13 6月, 2018 2 次提交
  15. 29 5月, 2018 1 次提交
  16. 11 5月, 2018 1 次提交
  17. 19 4月, 2018 2 次提交
  18. 26 3月, 2018 1 次提交
  19. 23 3月, 2018 1 次提交
    • S
      hv_netvsc: common detach logic · 7b2ee50c
      Stephen Hemminger 提交于
      Make common function for detaching internals of device
      during changes to MTU and RSS. Make sure no more packets
      are transmitted and all packets have been received before
      doing device teardown.
      
      Change the wait logic to be common and use usleep_range().
      
      Changes transmit enabling logic so that transmit queues are disabled
      during the period when lower device is being changed. And enabled
      only after sub channels are setup. This avoids issue where it could
      be that a packet was being sent while subchannel was not initialized.
      
      Fixes: 8195b139 ("hv_netvsc: fix deadlock on hotplug")
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b2ee50c
  20. 09 3月, 2018 1 次提交
  21. 14 12月, 2017 7 次提交
  22. 03 12月, 2017 2 次提交
  23. 16 11月, 2017 1 次提交
    • V
      hv_netvsc: preserve hw_features on mtu/channels/ringparam changes · aefd80e8
      Vitaly Kuznetsov 提交于
      rndis_filter_device_add() is called both from netvsc_probe() when we
      initially create the device and from set channels/mtu/ringparam
      routines where we basically remove the device and add it back.
      
      hw_features is reset in rndis_filter_device_add() and filled with
      host data. However, we lose all additional flags which are set outside
      of the driver, e.g. register_netdevice() adds NETIF_F_SOFT_FEATURES and
      many others.
      
      Unfortunately, calls to rndis_{query_hwcaps(), _set_offload_params()}
      calls cannot be avoided on every RNDIS reset: host expects us to set
      required features explicitly. Moreover, in theory hardware capabilities
      can change and we need to reflect the change in hw_features.
      
      Reset net->hw_features bits according to host data in
      rndis_netdev_set_hwcaps(), clear corresponding feature bits
      from net->features in case some features went missing (will never happen
      in real life I guess but let's be consistent).
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Reviewed-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aefd80e8
  24. 15 10月, 2017 2 次提交
  25. 09 10月, 2017 1 次提交
  26. 01 10月, 2017 1 次提交
  27. 22 9月, 2017 1 次提交
    • A
      hv_netvsc: fix send buffer failure on MTU change · 0ab09bef
      Alex Ng 提交于
      If MTU is changed the host would reject the send buffer change.
      This problem is result of recent change to allow changing send
      buffer size.
      
      Every time we change the MTU, we store the previous net_device section
      count before destroying the buffer, but we don’t store the previous
      section size. When we reinitialize the buffer, its size is calculated
      by multiplying the previous count and previous size. Since we
      continuously increase the MTU, the host returns us a decreasing count
      value while the section size is reinitialized to 1728 bytes every
      time.
      
      This eventually leads to a condition where the calculated buf_size is
      so small that the host rejects it.
      
      Fixes: 8b532797 ("netvsc: allow controlling send/recv buffer size")
      Signed-off-by: NAlex Ng <alexng@microsoft.com>
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ab09bef