1. 14 10月, 2017 3 次提交
    • A
      i40e: Enable 'channel' mode in mqprio for TC configs · a9ce82f7
      Amritha Nambiar 提交于
      The i40e driver is modified to enable the new mqprio hardware
      offload mode and factor the TCs and queue configuration by
      creating channel VSIs. In this mode, the priority to traffic
      class mapping and the user specified queue ranges are used
      to configure the traffic classes by setting the mode option to
      'channel'.
      
      Example:
        map 0 0 0 0 1 2 2 3 queues 2@0 2@2 1@4 1@5\
        hw 1 mode channel
      
      qdisc mqprio 8038: root  tc 4 map 0 0 0 0 1 2 2 3 0 0 0 0 0 0 0 0
                   queues:(0:1) (2:3) (4:4) (5:5)
                   mode:channel
                   shaper:dcb
      
      The HW channels created are removed and all the queue configuration
      is set to default when the qdisc is detached from the root of the
      device.
      
      This patch also disables setting up channels via ethtool (ethtool -L)
      when the TCs are configured using mqprio scheduler.
      
      The patch also limits setting ethtool Rx flow hash indirection
      (ethtool -X eth0 equal N) to max queues configured via mqprio.
      The Rx flow hash indirection input through ethtool should be
      validated so that it is within in the queue range configured via
      tc/mqprio. The bound checking is achieved by reporting the current
      rss size to the kernel when queues are configured via mqprio.
      
      Example:
        map 0 0 0 1 0 2 3 0 queues 2@0 4@2 8@6 11@14\
        hw 1 mode channel
      
      Cannot set RX flow hash configuration: Invalid argument
      Signed-off-by: NAmritha Nambiar <amritha.nambiar@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a9ce82f7
    • A
      i40e: Add infrastructure for queue channel support · 8f88b303
      Amritha Nambiar 提交于
      This patch sets up the infrastructure for offloading TCs and
      queue configurations to the hardware by creating HW channels(VSI).
      A new channel is created for each of the traffic class
      configuration offloaded via mqprio framework except for the first TC
      (TC0). TC0 for the main VSI is also reconfigured as per user provided
      queue parameters. Queue counts that are not power-of-2 are handled by
      reconfiguring RSS by reprogramming LUTs using the queue count value.
      This patch also handles configuring the TX rings for the channels,
      setting up the RX queue map for channel.
      
      Also, the channels so created are removed and all the queue
      configuration is set to default when the qdisc is detached from the
      root of the device.
      Signed-off-by: NAmritha Nambiar <amritha.nambiar@intel.com>
      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>
      8f88b303
    • A
      i40e: Add macro for PF reset bit · ff424188
      Amritha Nambiar 提交于
      Introduce a macro for the bit setting the PF reset flag and
      update its usages. This makes it easier to use this flag
      in functions to be introduced in future without encountering
      checkpatch issues related to alignment and line over 80
      characters.
      Signed-off-by: NAmritha Nambiar <amritha.nambiar@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ff424188
  2. 13 10月, 2017 6 次提交
  3. 12 10月, 2017 16 次提交
  4. 11 10月, 2017 14 次提交
  5. 10 10月, 2017 1 次提交
    • B
      e1000e: Avoid receiver overrun interrupt bursts · 4aea7a5c
      Benjamin Poirier 提交于
      When e1000e_poll() is not fast enough to keep up with incoming traffic, the
      adapter (when operating in msix mode) raises the Other interrupt to signal
      Receiver Overrun.
      
      This is a double problem because 1) at the moment e1000_msix_other()
      assumes that it is only called in case of Link Status Change and 2) if the
      condition persists, the interrupt is repeatedly raised again in quick
      succession.
      
      Ideally we would configure the Other interrupt to not be raised in case of
      receiver overrun but this doesn't seem possible on this adapter. Instead,
      we handle the first part of the problem by reverting to the practice of
      reading ICR in the other interrupt handler, like before commit 16ecba59
      ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit
      0a8047ac ("e1000e: Fix msi-x interrupt automask") which cleared IAME
      from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts
      anymore. We handle the second part of the problem by not re-enabling the
      Other interrupt right away when there is overrun. Instead, we wait until
      traffic subsides, napi polling mode is exited and interrupts are
      re-enabled.
      Reported-by: NLennart Sorensen <lsorense@csclub.uwaterloo.ca>
      Fixes: 16ecba59 ("e1000e: Do not read ICR in Other interrupt")
      Signed-off-by: NBenjamin Poirier <bpoirier@suse.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4aea7a5c