1. 20 Apr, 2017 9 commits
    • Jacob Keller's avatar
      i40e: use i40e_stop_rings_no_wait to implement PORT_SUSPENDED state · 3480756f
      Jacob Keller authored
      This state bit was added as a way for DCB to avoid having to wait for
      the queues to disable when handling LLDP events. The logic for this was
      burried deep within stop Tx and stop Rx queue code. First, let's rename
      it so that it does not appear to only affect Tx when infact it modifies
      both Tx and Rx flow. Second we can move it up into the i40e_stop_rings()
      function, and we can simply re-use the i40e_stop_rings_no_wait() so that
      we don't have to bury the implementation as deep into the call stack.
      
      An alternative might be to remove the state bit and instead attempt to
      shut down everything directly in DCP flow. This, however, is not ideal
      because it creates yet another separate shutdown routine that we'd have
      to maintain. In the current implementation any changes will be made to
      both flows.
      
      Change-ID: I68e1ccb901af320862bca395e9c9746f08e8b17c
      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>
      3480756f
    • Jacob Keller's avatar
      i40e: reset all VFs in parallel when rebuilding PF · e4b433f4
      Jacob Keller authored
      When there are a lot of active VFs, it can take multiple seconds to
      finish resetting all of them during certain flows., which can cause some
      VFs to fail to wait long enough for the reset to occur. The user might
      see messages like "Never saw reset" or "Reset never finished" and the VF
      driver will stop functioning properly.
      
      The naive solution would be to simply increase the wait timer. We can
      get much more clever. Notice that i40e_reset_vf is run in a serialized
      fashion, and includes lots of delays.
      
      There are two prominent delays which take most of the time. First, when
      we begin resetting VFs, we have multiple 10ms delays which accrue
      because we reset each VF in a serial fashion. These delays accumulate to
      almost 4 seconds when handling the maximum number of VFs (128).
      
      Secondly, there is a massive 50ms delay for each time we disable queues
      on a VSI. This delay is necessary to allow HW to finish disabling queues
      before we restore functionality. However, just like with the first case,
      we are paying the cost for each VF, rather than disabling all VFs and
      waiting once.
      
      Both of these can be fixed, but required some previous refactoring to
      handle the special case. First, we will need the
      i40e_vsi_wait_queues_disabled function which was previously DCB
      specific. Second, we will need to implement our own
      i40e_vsi_stop_rings_no_wait function which will handle the stopping of
      rings without the delays.
      
      Finally, implement an i40e_reset_all_vfs function, which will first
      start the reset of all VFs, and pay the wait cost all at once, rather
      than serially waiting for each VF before we start processing then next
      one. After the VF has been reset, we'll disable all the VF queues, and
      then wait for them to disable. Again, we'll organize the flow such that
      we pay the wait cost only once.
      
      Finally, after we've disabled queues we'll go ahead and begin restoring
      VF functionality. The result is reducing the wait time by a large factor
      and ensuring that VFs do not timeout when waiting in the VF driver.
      
      Change-ID: Ia6e8cf8d98131b78aec89db78afb8d905c9b12be
      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>
      e4b433f4
    • Jacob Keller's avatar
      i40e: split some code in i40e_reset_vf into helpers · 9dc2e417
      Jacob Keller authored
      A future patch is going to want to re-use some of the code in
      i40e_reset_vf, so lets break up the beginning and ending parts into
      their own helper functions. The first function will be used to
      initialize the reset on a VF, while the second function will be used to
      finalize the reset and restore functionality.
      
      Change-ID: I48df808b8bf09de3c2ed8c521f57b3f0ab9e5907
      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>
      9dc2e417
    • Jacob Keller's avatar
      i40e: remove I40E_FLAG_IN_NETPOLL entirely · 1de81c2d
      Jacob Keller authored
      This flag was originally intended to be used to let some
      driver code know when we were running from netpoll.
      Ultimately this was not necessary and we never used it.
      Let's remove it
      
      Change-ID: I43b72483d91c1638071d2a7f389ab171ec5b796a
      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>
      1de81c2d
    • Jacob Keller's avatar
      i40e: reduce wait time for adminq command completion · 9e3f23f4
      Jacob Keller authored
      When sending an adminq command, we wait for the command to complete in
      a loop. This loop waits for an entire millisecond, when in practice the
      adminq command is processed often much faster.
      
      Change the loop to use i40e_usec_delay instead, and wait for 50 usecs
      each time instead. This appears to be about the minimum time required,
      based on some manual observation and testing.
      
      The primary benefit of this change is reducing latency of various
      operations in the PF driver, especially when related to having a large
      number of VFs enabled.
      
      For example, on Linux, when instantiating 128 VFs, the time to finish
      the operation dropped from about 9 seconds down to under 6 seconds.
      Additionally, the time it takes to finish a PF reset with 128 VFs
      dropped from 5.1 seconds down to 0.7 seconds.
      
      As the examples above show, a significant portion of the delay is wasted
      waiting for admiqn operations which have already finished.
      
      This patch shouldn't cause impact to functionality, as we still check
      and keep waiting until the command does get processed. The only expected
      change is an increase in CPU utilization as we now check for completion
      far more times. However, in practice the commands appear to generally be
      complete within the first delay window anyways.
      
      Change-ID: If8af8388e100da0a14eaf9e1af3afadf73a958cf
      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>
      9e3f23f4
    • Jacob Keller's avatar
      i40e: fix CONFIG_BUSY checks in i40e_set_settings function · e8d2f4c6
      Jacob Keller authored
      The check for I40E_CONFIG_BUSY state bit in the i40e_set_link_ksettings
      function is fishy. First we can notice a few things about the check here.
      
      First a similar check was introduced by commit
      'c7d05ca8 ("i40e: driver ethtool core")'
      
      Later a commit introducing the link settings was added by commit
      'bf9c7141 ("i40e: Implement set_settings for ethtool")'
      
      However, this second check was against vsi->state instead of pf->state,
      and also failed to set the bit, it only checks. That indicates the locking
      was not quite correct. The only other place that the state bit
      in vsi->state gets used is to protect the filter list.
      
      Since this code does not care about the mac filter list,  and seems
      clear the original code should have set the pf->state bit. Fix these
      issues by using pf->state correctly, and by actually setting the bit
      so that we properly lock as expected.
      
      Since these checks occur while holding the rtnl_lock(), lets also add a
      timeout so that we don't potentially softlock the system.
      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>
      e8d2f4c6
    • Jacob Keller's avatar
      i40e: factor out queue control from i40e_vsi_control_(tx|rx) · c768e490
      Jacob Keller authored
      A future patch will need to be able to handle controlling queues without
      waiting until all VSIs are handled. Factor out the direct queue
      modification so that we can easily re-use this code. The result is also
      a bit easier to read since we don't embed multiple single-letter loop
      counters.
      
      Change-ID: Id923cbfa43127b1c24d8ed4f809b1012c736d9ac
      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>
      c768e490
    • Jacob Keller's avatar
      i40e: don't hold RTNL lock while waiting for VF reset to finish · 024b05f4
      Jacob Keller authored
      We made some effort to reduce the RTNL lock scope when resetting and
      rebuilding the PF. Unfortunately we still held the RTNL lock during the
      VF reset operation, which meant that multiple PFs could not reset in
      parallel due to the global lock. For now, further reduce the scope by
      not holding the RTNL lock while resetting VFs. This allows multiple PFs
      to reset in a timely manner.
      
      Change-ID: I2fbf823a0063f24dff67676cad09f0bbf83ee4ce
      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>
      024b05f4
    • Jingjing Wu's avatar
      i40e: new AQ commands · 1d5c960c
      Jingjing Wu authored
      Add admin queue functions for Pipeline Personalization Profile AQ
      commands:
       - Write Recipe Command buffer (Opcode: 0x0270)
       - Get Applied Profiles list (Opcode: 0x0271)
      
      Change-ID: I558b4145364140f624013af48d4bbf79d21ebb0d
      Signed-off-by: default avatarJingjing Wu <jingjing.wu@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1d5c960c
  2. 19 Apr, 2017 5 commits
    • Scott Peterson's avatar
      i40e/i40evf: Add tracepoints · ed0980c4
      Scott Peterson authored
      This patch adds tracepoints to the i40e and i40evf drivers to which
      BPF programs can be attached for feature testing and verification.
      It's expected that an attached BPF program will identify and count or
      log some interesting subset of traffic. The bcc-tools package is
      helpful there for containing all the BPF arcana in a handy Python
      wrapper. Though you can make these tracepoints log trace messages, the
      messages themselves probably won't be very useful (other to verify the
      tracepoint is being called while you're debugging your BPF program).
      
      The idea here is that tracepoints have such low performance cost when
      disabled that we can leave these in the upstream drivers. This may
      eventually enable the instrumentation of unmodified customer systems
      should the need arise to verify a NIC feature is working as expected.
      In general this enables one set of feature verification tools to be
      used on these drivers whether they're built with the kernel or
      separately.
      
      Users are advised against using these tracepoints for anything other
      than a diagnostic tool. They have a performance impact when enabled,
      and their exact placement and form may change as we see how well they
      work in practice for the purposes above.
      
      Change-ID: Id6014a7322c0e6d08068114dd20bd156f2f6435e
      Signed-off-by: default avatarScott Peterson <scott.d.peterson@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ed0980c4
    • Mitch Williams's avatar
      i40e: dump VF information in debugfs · 3118025a
      Mitch Williams authored
      Dump some internal state about VFs through debugfs. This provides
      information not available with 'ip link show'. To use, write "dump vf
      <id>" to the command file, or just "dump vf" to dump information on all
      of the VFs.
      
      Change-ID: Ibe32b7f4ae55d4358c0b903217475f708ada1ecd
      Signed-off-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>
      3118025a
    • Alexander Duyck's avatar
      i40e: Fix support for flow director programming status · 0e626ff7
      Alexander Duyck authored
      This patch fixes an issue I introduced when I converted the code over to
      using the length field to determine if a descriptor was done or not. It
      turns out that we are also processing programming descriptors in the Rx
      path and need to have these processed even though the length field will be
      0 on these packets.  What will happen with a programming descriptor is that
      we will receive a descriptor that has the SPH bit set, and the header
      length and packet length fields cleared.
      
      To account for this we should be checking for the bit for split header
      being set even though we aren't actually using header split. This bit is
      set in the length field to indicate if a programming descriptor response is
      contained in the descriptor. Since we don't support header split we don't
      need to perform the extra checks of using a fixed value for the entire
      length field.
      
      In addition I am moving the function for checking if a filter is a
      programming status filter into the i40e_txrx.c file since there is no
      longer support for FCoE it doesn't make sense to keep this file in i40e.h.
      
      Change-ID: I12c359c3dc70adb9d6b92b27324bb2c7f04c1a06
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0e626ff7
    • alice michael's avatar
      i40e/i40evf: Remove VF Rx csum offload for tunneled packets · 53240e99
      alice michael authored
      Rx checksum offload for tunneled packets was never being negotiated or
      requested by VF. This capability was assumed by default and enabled in
      current hardware for VF. Going forward, this feature needs to be disabled
      or advanced ptypes should be negotiated with PF in the future.
      
      Change-ID: I9e54cfa8a90e03ab6956db4412f1e337ccd2c2e0
      Signed-off-by: default avatarPreethi Banala <preethi.banala@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      53240e99
    • Tobias Klauser's avatar
      i40evf: Use net_device_stats from struct net_device · 4a0a3abf
      Tobias Klauser authored
      Instead of using a private copy of struct net_device_stats in
      struct i40evf_adapter, use stats from struct net_device. Also remove the
      now unnecessary .ndo_get_stats function.
      Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4a0a3abf
  3. 18 Apr, 2017 26 commits