1. 10 Oct, 2017 23 commits
  2. 09 Oct, 2017 17 commits
    • David S. Miller's avatar
      Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 0349a86c
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      10GbE Intel Wired LAN Driver Updates 2017-10-09
      
      This series contains updates to ixgbe only.
      
      Emil fixes an issue where the semaphore bits could be stuck after a reset
      or a crash, by adding the clearing of software resource bits in the
      software/firmware synchronization register.  Added error checks when we
      attempt to identify and initialize the PHY to prevent a crash.  Fixed a
      few issues in the logic of ixgbe_clean_test_rings() which was exposed by
      a previous commit that was causing a crash in ethtool diagnostics.
      
      Bhumika Goyal fixes a couple of instances which were overlooked when we
      made ixgbe_mac_operations constant.
      
      Shannon Nelson fixes an issue to restore normal operations after the
      last MACVLAN offload is removed, otherwise we get stuck in a single queue
      operations.
      
      The infamous Jesper Dangaard Brouer adds a counter which counts the
      number of times the recycle fails and the real page allocator is invoked.
      
      Alex updates the adaptive ITR algorithm to better support the needs of the
      network.  This attempt to make it so that our ITR algorithm will try to
      prevent either starving a socket buffer for memory in the case of
      transmit, or overrunning an receive socket buffer on receive.  We should
      function better with new features like XDP which can handle small packets
      at high rates without needing to lock us into NAPI polling mode.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0349a86c
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · ff33952e
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Fix object leak on IPSEC offload failure, from Steffen Klassert.
      
       2) Fix range checks in ipset address range addition operations, from
          Jozsef Kadlecsik.
      
       3) Fix pernet ops unregistration order in ipset, from Florian Westphal.
      
       4) Add missing netlink attribute policy for nl80211 packet pattern
          attrs, from Peng Xu.
      
       5) Fix PPP device destruction race, from Guillaume Nault.
      
       6) Write marks get lost when BPF verifier processes R1=R2 register
          assignments, causing incorrect liveness information and less state
          pruning. Fix from Alexei Starovoitov.
      
       7) Fix blockhole routes so that they are marked dead and therefore not
          cached in sockets, otherwise IPSEC stops working. From Steffen
          Klassert.
      
       8) Fix broadcast handling of UDP socket early demux, from Paolo Abeni.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (37 commits)
        cdc_ether: flag the u-blox TOBY-L2 and SARA-U2 as wwan
        net: thunderx: mark expected switch fall-throughs in nicvf_main()
        udp: fix bcast packet reception
        netlink: do not set cb_running if dump's start() errs
        ipv4: Fix traffic triggered IPsec connections.
        ipv6: Fix traffic triggered IPsec connections.
        ixgbe: incorrect XDP ring accounting in ethtool tx_frame param
        net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
        Revert commit 1a8b6d76 ("net:add one common config...")
        ixgbe: fix masking of bits read from IXGBE_VXLANCTRL register
        ixgbe: Return error when getting PHY address if PHY access is not supported
        netfilter: xt_bpf: Fix XT_BPF_MODE_FD_PINNED mode of 'xt_bpf_info_v1'
        netfilter: SYNPROXY: skip non-tcp packet in {ipv4, ipv6}_synproxy_hook
        tipc: Unclone message at secondary destination lookup
        tipc: correct initialization of skb list
        gso: fix payload length when gso_size is zero
        mlxsw: spectrum_router: Avoid expensive lookup during route removal
        bpf: fix liveness marking
        doc: Fix typo "8023.ad" in bonding documentation
        ipv6: fix net.ipv6.conf.all.accept_dad behaviour for real
        ...
      ff33952e
    • Aleksander Morgado's avatar
      cdc_ether: flag the u-blox TOBY-L2 and SARA-U2 as wwan · fdfbad32
      Aleksander Morgado authored
      The u-blox TOBY-L2 is a LTE Cat 4 module with HSPA+ and 2G fallback.
      This module allows switching to different USB profiles with the
      'AT+UUSBCONF' command, and provides a ECM network interface when the
      'AT+UUSBCONF=2' profile is selected.
      
      The u-blox SARA-U2 is a HSPA module with 2G fallback. The default USB
      configuration includes a ECM network interface.
      
      Both these modules are controlled via AT commands through one of the
      TTYs exposed. Connecting these modules may be done just by activating
      the desired PDP context with 'AT+CGACT=1,<cid>' and then running DHCP
      on the ECM interface.
      Signed-off-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fdfbad32
    • Stefano Brivio's avatar
      i40e: Avoid some useless variables and initializers in NVM functions · 2c4d36b7
      Stefano Brivio authored
      Fixes: 09f79fd4 ("i40e: avoid NVM acquire deadlock during NVM update")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      2c4d36b7
    • Rami Rosen's avatar
      i40e: fix a typo · 3d7d7a86
      Rami Rosen authored
      This patch fixes a typo in i40e_vsi_alloc_arrays() documentation.
      The first parameter name should be "vsi" instead of "type".
      Signed-off-by: default avatarRami Rosen <rami.rosen@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3d7d7a86
    • Lihong Yang's avatar
      i40e: use a local variable instead of calculating multiple times · 9bcc07f0
      Lihong Yang authored
      The computed result of I40E_MAX_VSI_QP * I40E_VIRTCHNL_SUPPORTED_QTYPES
      is used more than three times in function i40e_config_irq_link_list.
      Simply declare a local variable to store it to improve readability.
      Signed-off-by: default avatarLihong Yang <lihong.yang@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      9bcc07f0
    • Jayaprakash Shanmugam's avatar
      i40e: Retry AQC GetPhyAbilities to overcome I2CRead hangs · 4988410f
      Jayaprakash Shanmugam authored
      - When the I2C is busy, the PHY reads are delayed.  The firmware will
        return EGAIN in these cases with an expectation that the SW will
        trigger the reads again
      - This patch retries the operation for a maximum period of 500ms
      Signed-off-by: default avatarJayaprakash Shanmugam <jayaprakash.shanmugam@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4988410f
    • Lihong Yang's avatar
      i40e: add check for return from find_first_bit call · b861fb76
      Lihong Yang authored
      The find_first_bit function will return the size passed to search
      if the first set bit is not found. This patch adds the check in case
      that happens as the return value would be used as the index in an array
      and that would have caused the out-of-bounds access.
      
      Detected by CoverityScan, CID 1295969 Out-of-bounds access
      Signed-off-by: default avatarLihong Yang <lihong.yang@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b861fb76
    • Jacob Keller's avatar
      i40e: allow XPS with QoS enabled · 6f853d4f
      Jacob Keller authored
      Recently, the kernel gained support for enabling XPS and QoS at the
      same time. Thus, we no longer need to worry about the number of
      traffic classes when enabling XPS.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6f853d4f
    • Jacob Keller's avatar
      i40e/i40evf: bundle more descriptors when allocating buffers · 95bc2fb4
      Jacob Keller authored
      Double the number of descriptors we'll bundle into one tail bump when
      receiving. Empirical testing has shown that we reduce CPU utilization
      and don't appear to reduce throughput or packet rate. 32 seems to be the
      sweet spot, as it's half the default polling budget, so we'd essentially
      reduce from 4 tail writes when polling down to 2. Increasing this up to
      64 appears to have negative impacts as it may become possible that we
      don't bump the tail each time we get polled, which could cause a long
      delay between returning descriptors to the hardware.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      95bc2fb4
    • Jacob Keller's avatar
      i40e/i40evf: bump tail only in multiples of 8 · 11f29003
      Jacob Keller authored
      Hardware only fetches descriptors on cachelines of 8, essentially
      ignoring the lower 3 bits of the tail register. Thus, it is pointless to
      bump tail by an unaligned access as the hardware will ignore some of the
      new descriptors we allocated. Thus, it's ideal if we can ensure tail
      writes are always aligned to 8.
      
      At first, it seems like we'd already do this, since we allocate
      descriptors in batches which are a multiple of 8. Since we'd always
      increment by a multiple of 8, it seems like the value should always be
      aligned.
      
      However, this ignores allocation failures. If we fail to allocate
      a buffer, our tail register will become unaligned. Once it has become
      unaligned it will essentially be stuck unaligned until a buffer
      allocation happens to fail at the exact amount necessary to re-align it.
      
      We can do better, by simply rounding down the number of buffers we're
      about to allocate (cleaned_count) such that "next_to_clean
      + cleaned_count" is rounded to the nearest multiple of 8.
      
      We do this by calculating how far off that value is and subtracting it
      from the cleaned_count. This essentially defers allocation of buffers if
      they're going to be ignored by hardware anyways, and re-aligns our
      next_to_use and tail values after a failure to allocate a descriptor.
      
      This calculation ensures that we always align the tail writes in a way
      the hardware expects and don't unnecessarily allocate buffers which
      won't be fetched immediately.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      11f29003
    • Jacob Keller's avatar
      i40e: reduce lrxqthresh from 2 to 1 · 7362be9e
      Jacob Keller authored
      The lrxq thresh value tells hardware to immediately interrupt when there
      are fewer than N*64 packets left in the ring.
      
      Counter intuitively, empirical testing has shown that decreasing this
      value from 2 to 1, and thus changing from an immediate interrupt at
      fewer than 128 descriptors down to 64 descriptors causes a small
      increase in the maximum total packets per second we can receive. This
      increase occurs even when we're polling with interrupts masked, as the
      hardware must still handle interrupts internally even if we've disabled
      them in software.
      
      Also reduce the value for any VFs we allocate.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7362be9e
    • Jacob Keller's avatar
      i40e/i40evf: always set the CLEARPBA flag when re-enabling interrupts · dbadbbe2
      Jacob Keller authored
      In the past we changed driver behavior to not clear the PBA when
      re-enabling interrupts. This change was motivated by the flawed belief
      that clearing the PBA would cause a lost interrupt if a receive
      interrupt occurred while interrupts were disabled.
      
      According to empirical testing this isn't the case. Additionally, the
      data sheet specifically says that we should set the CLEARPBA bit when
      re-enabling interrupts in a polling setup.
      
      This reverts commit 40d72a50 ("i40e/i40evf: don't lose interrupts")
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      dbadbbe2
    • Jacob Keller's avatar
      i40e/i40evf: fix incorrect default ITR values on driver load · 42702559
      Jacob Keller authored
      The ITR register expects to be programmed in units of 2 microseconds.
      Because of this, all of the drivers I40E_ITR_* constants are in terms of
      this 2 microsecond register.
      
      Unfortunately, the rx_itr_default value is expected to be programmed in
      microseconds.
      
      Effectively the driver defaults to an ITR value of half the expected
      value (in terms of minimum microseconds between interrupts).
      
      Fix this by changing the default values to be calculated using
      ITR_REG_TO_USEC macro which indicates that we're converting from the
      register units into microseconds.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      42702559
    • Alan Brady's avatar
      i40evf: fix mac filter removal timing issue · c766b9af
      Alan Brady authored
      Due to the asynchronous nature in which mac filters are added and
      deleted, there exists a bug in which filters are erroneously removed if
      removed then added again quickly.
      
      The events are as such:
          - filter marked for removal
          - same filter is re-added before watchdog that cleans up filters
          - we skip re-adding the filter because we have it already in the
      list
          - watchdog filter cleanup kicks off and filter is removed
      
      So when we were re-adding the same filter, it didn't actually get added
      because it already existed in the list, but was marked for removal and
      had yet to actually be removed.
      
      This patch fixes the issue by making sure that when adding a filter, if
      we find it already existing in our list, make sure it is not marked to
      be removed.
      Signed-off-by: default avatarAlan Brady <alan.brady@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c766b9af
    • Lihong Yang's avatar
      i40e: use the safe hash table iterator when deleting mac filters · 784548c4
      Lihong Yang authored
      This patch replaces hash_for_each function with hash_for_each_safe
      when calling  __i40e_del_filter. The hash_for_each_safe function is
      the right one to use when iterating over a hash table to safely remove
      a hash entry. Otherwise, incorrect values may be read from freed memory.
      
      Detected by CoverityScan, CID 1402048 Read from pointer after free
      Signed-off-by: default avatarLihong Yang <lihong.yang@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      784548c4
    • Jacob Keller's avatar
      i40e: fix flags declaration · b48be997
      Jacob Keller authored
      Since we don't yet have more than 32 flags, we'll use a u32 for both the
      hw_features and flag field. Should we gain more flags in the future, we
      may need to convert to a u64 or separate flags out into two fields.
      
      This was overlooked in the previous commit 2781de2134c4 ("i40e/i40evf:
      organize and re-number feature flags"), where the feature flag was not
      converted form u64 to u32.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Reviewed-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b48be997