1. 15 7月, 2016 4 次提交
    • G
      i40e: use valid online CPU on q_vector initialization · 7f6c5539
      Guilherme G. Piccoli 提交于
      Currently, the q_vector initialization routine sets the affinity_mask
      of a q_vector based on v_idx value. Meaning a loop iterates on v_idx,
      which is an incremental value, and the cpumask is created based on
      this value.
      
      This is a problem in systems with multiple logical CPUs per core (like in
      SMT scenarios). If we disable some logical CPUs, by turning SMT off for
      example, we will end up with a sparse cpu_online_mask, i.e., only the first
      CPU in a core is online, and incremental filling in q_vector cpumask might
      lead to multiple offline CPUs being assigned to q_vectors.
      
      Example: if we have a system with 8 cores each one containing 8 logical
      CPUs (SMT == 8 in this case), we have 64 CPUs in total. But if SMT is
      disabled, only the 1st CPU in each core remains online, so the
      cpu_online_mask in this case would have only 8 bits set, in a sparse way.
      
      In general case, when SMT is off the cpu_online_mask has only C bits set:
      0, 1*N, 2*N, ..., C*(N-1)  where
      C == # of cores;
      N == # of logical CPUs per core.
      In our example, only bits 0, 8, 16, 24, 32, 40, 48, 56 would be set.
      
      This patch changes the way q_vector's affinity_mask is created: it iterates
      on v_idx, but consumes the CPU index from the cpu_online_mask instead of
      just using the v_idx incremental value.
      
      No functional changes were introduced.
      Signed-off-by: NGuilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7f6c5539
    • P
      ixgbe: napi_poll must return the work done · 4b732cd4
      Paolo Abeni 提交于
      Currently the function ixgbe_poll() returns 0 when it clean completely
      the rx rings, but this foul budget accounting in core code.
      Fix this returning the actual work done, capped to weight - 1, since
      the core doesn't allow to return the full budget when the driver modifies
      the napi status
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: NVenkatesh Srinivas <venkateshs@google.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4b732cd4
    • K
      i40e: enable VSI broadcast promiscuous mode instead of adding broadcast filter · f6bd0962
      Kiran Patil 提交于
      This patch sets VSI broadcast promiscuous mode during VSI add sequence
      and prevents adding MAC filter if specified MAC address is broadcast.
      
      Change-ID: Ia62251fca095bc449d0497fc44bec3a5a0136773
      Signed-off-by: NKiran Patil <kiran.patil@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f6bd0962
    • A
      i40e/i40evf: Fix i40e_rx_checksum · 858296c8
      Alexander Duyck 提交于
      There are a couple of issues I found in i40e_rx_checksum while doing some
      recent testing.  As a result I have found the Rx checksum logic is pretty
      much broken and returning that the checksum is valid for tunnels in cases
      where it is not.
      
      First the inner types are not the correct values to use to test for if a
      tunnel is present or not.  In addition the inner protocol types are not a
      bitmask as such performing an OR of the values doesn't make sense.  I have
      instead changed the code so that the inner protocol types are used to
      determine if we report CHECKSUM_UNNECESSARY or not.  For anything that does
      not end in UDP, TCP, or SCTP it doesn't make much sense to report a
      checksum offload since it won't contain a checksum anyway.
      
      This leaves us with the need to set the csum_level based on some value.
      For that purpose I am using the tunnel_type field.  If the tunnel type is
      GRENAT or greater then this means we have a GRE or UDP tunnel with an inner
      header.  In the case of GRE or UDP we will have a possible checksum present
      so for this reason it should be safe to set the csum_level to 1 to indicate
      that we are reporting the state of the inner header.
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      858296c8
  2. 30 6月, 2016 2 次提交
  3. 29 6月, 2016 1 次提交
    • J
      e1000e: keep VLAN interfaces functional after rxvlan off · 889ad456
      Jarod Wilson 提交于
      I've got a bug report about an e1000e interface, where a VLAN interface is
      set up on top of it:
      
      $ ip link add link ens1f0 name ens1f0.99 type vlan id 99
      $ ip link set ens1f0 up
      $ ip link set ens1f0.99 up
      $ ip addr add 192.168.99.92 dev ens1f0.99
      
      At this point, I can ping another host on vlan 99, ip 192.168.99.91.
      However, if I do the following:
      
      $ ethtool -K ens1f0 rxvlan off
      
      Then no traffic passes on ens1f0.99. It comes back if I toggle rxvlan on
      again. I'm not sure if this is actually intended behavior, or if there's a
      lack of software VLAN stripping fallback, or what, but things continue to
      work if I simply don't call e1000e_vlan_strip_disable() if there are
      active VLANs (plagiarizing a function from the e1000 driver here) on the
      interface.
      
      Also slipped a related-ish fix to the kerneldoc text for
      e1000e_vlan_strip_disable here...
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      889ad456
  4. 21 5月, 2016 2 次提交
  5. 17 5月, 2016 2 次提交
  6. 14 5月, 2016 28 次提交
  7. 06 5月, 2016 1 次提交