1. 03 12月, 2015 3 次提交
  2. 23 10月, 2015 2 次提交
    • H
      ixgbe, ixgbevf: Add new mbox API xcast mode · 8443c1a4
      Hiroshi Shimamoto 提交于
      The limitation of the number of multicast address for VF is not enough
      for the large scale server with SR-IOV feature. IPv6 requires the multicast
      MAC address for each IP address to handle the Neighbor Solicitation
      message. We couldn't assign over 30 IPv6 addresses to a single VF.
      
      This patch introduces the new mailbox API, IXGBE_VF_UPDATE_XCAST_MODE,
      to update multicast mode of VF. This adds 3 modes;
        - NONE     only L2 exact match addresses or Flow Director enabled
        - MULTI    BAM and ROMPE set
        - ALLMULTI BAM, ROMPE and MPE set
      
      If a guest VF user wants over 30 MAC multicast addresses, set IFF_ALLMULTI
      to request PF to update xcast mode to enable VF multicast promiscuous mode.
      
      On the other hand, enabling VF multicast promiscuous mode may affect
      security and performance in the network of the NIC. Only trusted VF can
      enable multicast promiscuous mode. The behavior of untrusted VF is the
      same as previous version.
      Signed-off-by: NHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
      Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8443c1a4
    • H
      ixgbe: Add new ndo to trust VF · 54011e4d
      Hiroshi Shimamoto 提交于
      Implements the new netdev op to trust VF in ixgbe.
      
      The administrator can turn on and off VF trusted by ip command which
      supports trust message.
       # ip link set dev eth0 vf 1 trust on
      or
       # ip link set dev eth0 vf 1 trust off
      
      Send a ping to reset VF on changing the status of trusting.
      VF driver will reconfigure its features on reset.
      Signed-off-by: NHiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
      Tested-by: NKrishneil Singh <Krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      54011e4d
  3. 24 9月, 2015 1 次提交
  4. 16 9月, 2015 1 次提交
    • A
      ixgbe: Limit lowest interrupt rate for adaptive interrupt moderation to 12K · 8ac34f10
      Alexander Duyck 提交于
      This patch updates the lowest limit for adaptive interrupt interrupt
      moderation to roughly 12K interrupts per second.
      
      The way I came about reaching 12K as the desired interrupt rate is by
      testing with UDP flows.  Specifically I had a simple test that ran a
      netperf UDP_STREAM test at varying sizes.  What I found was as the packet
      sizes increased the performance fell steadily behind until we were only
      able to receive at ~4Gb/s with a message size of 65507.  A bit of digging
      found that we were dropping packets for the socket in the network stack,
      and looking at things further what I found was I could solve it by increasing
      the interrupt rate, or increasing the rmem_default/rmem_max.  What I found was
      that when the interrupt coalescing resulted in more data being processed
      per interrupt than could be stored in the socket buffer we started losing
      packets and the performance dropped.  So I reached 12K based on the
      following math.
      
      rmem_default = 212992
      skb->truesize = 2994
      212992 / 2994 = 71.14 packets to fill the buffer
      
      packet rate at 1514 packet size is 812744pps
      71.14 / 812744 = 87.9us to fill socket buffer
      
      From there it was just a matter of choosing the interrupt rate and
      providing a bit of wiggle room which is why I decided to go with 12K
      interrupts per second as that uses a value of 84us.
      
      The data below is based on VM to VM over a direct assigned ixgbe interface.
      The test run was:
      	netperf -H <ip> -t UDP_STREAM"
      
      Socket  Message  Elapsed      Messages                   CPU      Service
      Size    Size     Time         Okay Errors   Throughput   Util     Demand
      bytes   bytes    secs            #      #   10^6bits/sec % SS     us/KB
      Before:
      212992   65507   60.00     1100662      0     9613.4     10.89    0.557
      212992           60.00      473474            4135.4     11.27    0.576
      
      After:
      212992   65507   60.00     1100413      0     9611.2     10.73    0.549
      212992           60.00      974132            8508.3     11.69    0.598
      
      Using bare metal the data is similar but not as dramatic as the throughput
      increases from about 8.5Gb/s to 9.5Gb/s.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8ac34f10
  5. 02 9月, 2015 2 次提交
  6. 10 6月, 2015 1 次提交
  7. 11 4月, 2015 3 次提交
  8. 10 4月, 2015 1 次提交
  9. 14 3月, 2015 1 次提交
  10. 06 2月, 2015 2 次提交
  11. 31 12月, 2014 1 次提交
  12. 06 12月, 2014 3 次提交
  13. 02 10月, 2014 1 次提交
  14. 18 9月, 2014 2 次提交
  15. 12 9月, 2014 1 次提交
    • A
      ixgbe: Refactor busy poll socket code to address multiple issues · adc81090
      Alexander Duyck 提交于
      This change addresses several issues in the current ixgbe implementation of
      busy poll sockets.
      
      First was the fact that it was possible for frames to be delivered out of
      order if they were held in GRO.  This is addressed by flushing the GRO buffers
      before releasing the q_vector back to the idle state.
      
      The other issue was the fact that we were having to take a spinlock on
      changing the state to and from idle.  To resolve this I have replaced the
      state value with an atomic and use atomic_cmpxchg to change the value from
      idle, and a simple atomic set to restore it back to idle after we have
      acquired it.  This allows us to only use a locked operation on acquiring the
      vector without a need for a locked operation to release it.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      adc81090
  16. 27 5月, 2014 1 次提交
  17. 23 5月, 2014 1 次提交
  18. 23 4月, 2014 1 次提交
  19. 19 4月, 2014 1 次提交
  20. 11 4月, 2014 1 次提交
  21. 01 4月, 2014 2 次提交
  22. 13 3月, 2014 1 次提交
  23. 03 3月, 2014 1 次提交
  24. 01 3月, 2014 1 次提交
  25. 18 1月, 2014 1 次提交
  26. 15 1月, 2014 3 次提交
  27. 18 12月, 2013 1 次提交