1. 03 3月, 2012 1 次提交
  2. 09 2月, 2012 1 次提交
  3. 03 2月, 2012 1 次提交
  4. 05 12月, 2011 2 次提交
    • J
      ixgbe: DCB: IEEE transitions may fail to reprogram hardware. · 43497cc2
      John Fastabend 提交于
      Transitioning through an IEEE DCBX version from a CEE DCBX
      and back (CEE->IEEE->CEE) may leave IEEE attributes programmed
      in the hardware. DCB uses a bit field in the set routines to
      determine which attributes PG, PFC, APP need to be reprogrammed.
      This is needed because user flow allows queueing a series
      of changes and then reprogramming the hardware with the
      entire set in one operation.
      
      When transitioning from IEEE DCBX mode back into CEE DCBX
      mode the PG and PFC bits need to be set so the possibly
      
      different CEE attributes get programmed into the device.
      
      This patch fixes broken logic that was evaluating to 0
      and never setting any bits. Further this removes some
      checks for num_tc in set routines. This logic only worked
      when the number of traffic classes and user priorities
      were equal. This is no longer the case for X540 devices.
      Besides we can trust user input in this case if the
      device is incorrectly configured the DCB bandwidths will
      be incorrectly mapped but no OOPs, BUG, or hardware
      failure will occur.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      43497cc2
    • J
      ixgbe: DCBnl set_all, order of operations fix · 4909fe97
      John Fastabend 提交于
      The order of operations is important in DCBnl set_all(). When FCoE
      is configured it uses the up2tc map to learn which queues to configure
      the hardware offloads on. Therefore we need to setup the map before
      configuring FCoE.
      
      This is only seen when the both up2tc mappings and APP info are
      configured simultaneously.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4909fe97
  5. 03 11月, 2011 1 次提交
  6. 13 10月, 2011 1 次提交
  7. 06 10月, 2011 1 次提交
  8. 24 9月, 2011 2 次提交
  9. 29 8月, 2011 1 次提交
  10. 19 8月, 2011 1 次提交
  11. 11 8月, 2011 1 次提交
  12. 25 6月, 2011 3 次提交
  13. 24 6月, 2011 1 次提交
  14. 21 6月, 2011 3 次提交
  15. 14 4月, 2011 2 次提交
  16. 31 3月, 2011 1 次提交
  17. 12 3月, 2011 7 次提交
    • J
      ixgbe: IEEE 802.1Qaz, implement priority assignment table · 17049d30
      John Fastabend 提交于
      This patch adds support to use the priority assignment
      table in the ieee_ets structure to map priorities to
      traffic classes. Previously ixgbe only supported a
      1:1 mapping. Now we can enable and disable hardware
      DCB support when multiple traffic classes are actually
      being used. This allows the default case all priorities
      mapped to traffic class 0 to work in normal hardware
      mode and utilize the full packet buffer.
      
      This patch does not address putting the hardware in
      4TC mode so packet buffer space may be underutilized
      in this case. A follow up patch can address this
      optimization. But at least we have the hooks to do
      this now.
      
      Also CEE will behave as it always has and map priorities
      1:1 with traffic classes.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      17049d30
    • J
      ixgbe: DCB, missed translation from 8021Qaz TSA to CEE link strict · 3b97fd69
      John Fastabend 提交于
      The patch below  allowed IEEE 802.1Qaz and CEE DCB hardware
      configurations to use common hardware set routines,
      
      commit 88eb696cc6a7af8f9272266965b1a4dd7d6a931b
      Author: John Fastabend <john.r.fastabend@intel.com>
      Date:   Thu Feb 10 03:02:11 2011 -0800
      
          ixgbe: DCB, abstract out dcb_config from DCB hardware configuration
      
      However the case when CEE link strict and group strict
      are set was missed and are currently being mapped
      incorrectly in some configurations.
      
      This patch resolves this.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3b97fd69
    • J
      ixgbe: DCB: enable RSS to be used with DCB · 8187cd48
      John Fastabend 提交于
      RSS had previously been disabled when DCB was enabled because
      DCB was single queued per traffic class. Now that DCB implements
      multiple Tx/Rx rings per traffic class enable RSS.
      
      Here RSS hashes across the queues in the traffic class.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain.@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8187cd48
    • J
      ixgbe: DCB, use multiple Tx rings per traffic class · e5b64635
      John Fastabend 提交于
      This enables multiple {Tx|Rx} rings per traffic class while in DCB
      mode. In order to get this working as expected the tc_to_tx net
      device mapping is configured as well as the prio_tc_map.
      
      skb priorities are mapped across a range of queue pairs to get
      a distribution per traffic class. The maximum number of
      queue pairs used while in DCB mode is capped at 64. The hardware
      max is actually 128 queues but 64 is sufficient for now and
      allocating more seemed a bit excessive. It is easy enough to
      increase the cap later if need be.
      
      To get the 802.1Q priority tags inserted correctly ixgbe was
      previously using the skb queue_mapping field to directly set
      the 802.1Q priority. This no longer works because we have removed
      the 1:1 mapping between queues and traffic class. Each ring
      is aligned with an 802.1Qaz traffic class so here we add an
      extra field to the ring struct to identify the 802.1Q traffic
      class. This uses an extra byte of the ixgbe_ring struct
      fortunately there was a 2byte hole,
      
      struct ixgbe_ring {
              void *                     desc;                 /*     0     8 */
              struct device *            dev;                  /*     8     8 */
              struct net_device *        netdev;               /*    16     8 */
              union {
                      struct ixgbe_tx_buffer * tx_buffer_info; /*           8 */
                      struct ixgbe_rx_buffer * rx_buffer_info; /*           8 */
              };                                               /*    24     8 */
              long unsigned int          state;                /*    32     8 */
              u8                         atr_sample_rate;      /*    40     1 */
              u8                         atr_count;            /*    41     1 */
              u16                        count;                /*    42     2 */
              u16                        rx_buf_len;           /*    44     2 */
              u16                        next_to_use;          /*    46     2 */
              u16                        next_to_clean;        /*    48     2 */
              u8                         queue_index;          /*    50     1 */
              u8                         reg_idx;              /*    51     1 */
              u16                        work_limit;           /*    52     2 */
      
              /* XXX 2 bytes hole, try to pack */
      
              u8 *                       tail;                 /*    56     8 */
              /* --- cacheline 1 boundary (64 bytes) --- */
      
      Now we can set the VLAN priority directly and it will be
      correct. User space can indicate the 802.1Qaz priority
      using the SO_PRIORITY setsocket() option and QOS layer will
      steer the skb to the correct rings. Additionally using
      the multiq qdisc with a queue_mapping action works as
      well.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e5b64635
    • J
      ixgbe: DCB remove ixgbe_fcoe_getapp routine · dc166e22
      John Fastabend 提交于
      Remove ixgbe_fcoe_getapp() and use the generic kernel
      routine instead. Also add application priority to the
      kernel maintained list on setapp so applications and
      stacks can query the value.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      dc166e22
    • J
      ixgbe: DCB, implement ieee_setapp dcbnl ops · f8628d40
      John Fastabend 提交于
      Implement ieee_setapp dcbnl ops in ixgbe. This is required
      to setup FCoE which requires dedicated resources. If the
      app data is not for FCoE then no action is taken in ixgbe
      except to add it to the dcb_app_list.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f8628d40
    • J
      ixgbe: DCB, implement capabilities flags · 3032309b
      John Fastabend 提交于
      This implements dcbnl get and set capabilities ops. The
      devices supported by ixgbe can be configured to run in
      IEEE or CEE modes but not both.
      
      With the DCBX set capabilities bit we add an explicit
      signal that must be used to toggle between these modes.
      This patch adds logic to fail the CEE command set_hw_all()
      which programs the device with a CEE configuration if
      the CEE caps bit is not set. Similarly, IEEE set
      commands will fail if the IEEE caps bit is not set. We
      allow most CEE config set commands to occur because they
      do not touch the hardware until set_hw_all() is called.
      
      The one exception to the above is the {set|get}app routines.
      These must always be protected by caps bits to ensure
      side effects do not corrupt the current configured mode.
      
      By requiring the caps bit to be set correctly we can
      maintain a consistent configuration in the hardware
      for CEE or IEEE modes and prevent partial hardware
      configurations that may occur if user space does
      not send a complete IEEE or CEE configurations.
      
      It is expected that user space will signal a DCBX mode
      before programming device.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3032309b
  18. 03 3月, 2011 1 次提交
  19. 12 2月, 2011 6 次提交
  20. 17 11月, 2010 1 次提交
  21. 06 7月, 2010 1 次提交
  22. 04 6月, 2010 1 次提交