1. 25 2月, 2015 5 次提交
    • N
      i40e: Add support for getlink, setlink ndo ops · 51616018
      Neerav Parikh 提交于
      Add support for bridge offload ndo_ops getlink and setlink to
      enable bridge hardware mode as per the mode set via IFLA_BRIDGE_MODE.
      The support is only enabled in case of a PF VSI and not available for
      any other VSI type.
      
      By default the i40e driver inserts a bridge as part of the bring-up
      when a FDIR type VSI and/or a FCoE VSI is created. This bridge is
      created in VEB mode by default i.e. after creating the bridge using
      "Add VEB" AQ command the loopback for the PF's default VSI is enabled.
      
      The patch adds capability where all the VSIs created as downlink to
      the bridge inherits the loopback property and enables loopback only
      if the uplink bridge is operating in VEB mode.
      Hence, there is no need to explicitly enable loopback as part of
      allocating resources for SR-IOV VFs and call to do that has been
      removed.
      
      In case a user-request is made either via "bridge" utility or using
      the bridge netlink interface that requires to change the hardware
      bridge mode then that would require a PF reset and rebuild of the
      switch hierarchy.
      
      Also update the copyright year.
      
      Change-ID: I4d78fc1c83158efda29ba7be92239b74f75d6d25
      Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
      Tested-By: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      51616018
    • G
      i40e: Implement configfs for NPAR BW configuration · 96664483
      Greg Rose 提交于
      Add configfs controls to get, set and commit NPAR BW configurations.
      
      We export three controls:
      	min_bw - Can take a value from 0 to 100 inclusive
      	max_bw - Can take a value from 1 to 100 inclusive
      	commit - A write-only control that accepts only a value of 1 and will
      		cause the BW settings to be permanently committed to NVM so
      		that they are persistent across power cycles and system
      		resets
      
      The BW values are relative and are expressed as percentages.  For more
      information on the interpretation of the BW settings see the Dell
      specifications for NPAR.
      
      Also update the copyright year.
      
      Change-ID: Id7496ca65630b5037e32ba6a5a748fbc1632881b
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-By: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      96664483
    • G
      i40e: Add NPAR BW get and set functions · f4492db1
      Greg Rose 提交于
      We need to be able to get, set and commit permanently the NPAR
      partition BW configuration through configfs.  These are necessary
      precursor functions for that feature.
      
      Also update the copyright year.
      
      Change-ID: I9d5ca160a9288145f1dd2042994028679fff55f3
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f4492db1
    • M
      i40e: enable packet split only when IOMMU present · 2bc7ee8a
      Mitch Williams 提交于
      When an IOMMU is in use, the packet split receive path shows a distinct
      advantage over the single-buffer path because it minimizes DMA mapping
      and unmapping. However, this is not an advantage for systems with no
      IOMMU. At init time, check to see if an IOMMU is enabled and enable
      packet split receives.
      
      Change-ID: I4f70d2e9c31bbea3dc8fd0c5734959a6e6602210
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Tested-by: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      2bc7ee8a
    • C
      i40e/i40evf: Use advertised speed settings in ethtool and refactor get_settings · e827845c
      Catherine Sullivan 提交于
      Add a requested speed variable to the link_status struct to store the
      last speeds we requested from the firmware (the speeds the FW will be
      advertising with if autoneg is enabled).
      
      Use the advertised speed settings in get_settings in ethtool now that
      we have it.  Also set the requested speed settings in set_settings in
      ethtool as they are requested and initialize them in probe based on what
      the firmware remembers as the last requested speeds.
      
      To accommodate some longer lines in this new code, and improve
      readability I have added two functions i40e_get_settings_link_up
      and i40e_get_settings_link_down which get_settings now calls first.
      It then does all of the settings that happen regardless of link
      state. Some PHY types that supported the same settings were also combined.
      
      Also update the copyright year.
      
      Change-ID: Ica0c5ac81b6069ea6a7406fce7482f7816d4455c
      Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
      Tested-by: NJim Young <james.m.young@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e827845c
  2. 24 2月, 2015 6 次提交
  3. 09 2月, 2015 3 次提交
  4. 16 1月, 2015 8 次提交
  5. 14 1月, 2015 3 次提交
  6. 17 12月, 2014 1 次提交
  7. 06 12月, 2014 5 次提交
  8. 03 12月, 2014 2 次提交
  9. 23 11月, 2014 1 次提交
  10. 21 11月, 2014 2 次提交
  11. 18 11月, 2014 4 次提交
    • N
      i40e: Set XPS bit mask to zero in DCB mode · 3ffa037d
      Neerav Parikh 提交于
      Due to DCBX configuration change if the VSI needs to use more than 1 TC;
      it needs to disable the XPS maps that were set when operating in 1 TC mode.
      Without disabling XPS the netdev layer will select queues based on those
      settings and not use the TC queue mapping to make the queue selection.
      
      This patch allows the driver to enable/disable the XPS based on the number
      of TCs being enabled for the given VSI.
      
      Change-ID: Idc4dec47a672d2a509f6d7fe11ed1ee65b4f0e08
      Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
      Tested-By: NJack Morgan <jack.morgan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3ffa037d
    • N
      i40e: Do not disable/enable FCoE VSI with DCB reconfig · d341b7a5
      Neerav Parikh 提交于
      FCoE VSI Tx queue disable times out when reconfiguring as a result of
      DCB TC configuration change event.
      
      The hardware allows us to skip disabling and enabling of Tx queues for
      VSIs with single TC enabled. As FCoE VSI is configured to have only
      single TC we skip it from disable/enable flow.
      
      Change-ID: Ia73ff3df8785ba2aa3db91e6f2c9005e61ebaec2
      Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
      Tested-By: NJack Morgan <jack.morgan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d341b7a5
    • N
      i40e: Modify Tx disable wait flow in case of DCB reconfiguration · 69129dc3
      Neerav Parikh 提交于
      When DCB TC configuration changes the firmware suspends the port's Tx.
      Now, as DCB TCs may have changed the PF driver tries to reconfigure the
      TC configuration of the VSIs it manages. As part of this process it disables
      the VSI queues but the Tx queue disable will not complete as the port's
      Tx has been suspended. So, waiting for Tx queues to go to disable state
      in this flow may lead to detection of Tx queue disable timeout errors.
      
      Hence, this patch adds a new PF state so that if a port's Tx is in
      suspended state the Tx queue disable flow would just put the request for
      the queue to be disabled and return without waiting for the queue to be
      actually disabled.
      Once the VSI(s) TC reconfiguration has been done and driver has called
      firmware AQC "Resume PF Traffic" the driver checks the Tx queues requested
      to be disabled are actually disabled before re-enabling them again.
      
      Change-ID: If3e03ce4813a4e342dbd5a1eb1d2861e952b7544
      Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
      Tested-By: NJack Morgan <jack.morgan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      69129dc3
    • N
      i40e: Update VEB's enabled_tc after reconfiguration · 23cd1f09
      Neerav Parikh 提交于
      When the port TC configuration changes as a result of DCBx the driver
      modifies the enabled TCs for the VEBs it manages. But, in the process
      it did not update the enabled_tc value that it caches on a per VEB basis.
      
      So, when the next reconfiguration event occurs where the number of TC
      value is same as the value cached in enabled_tc for a given VEB; driver
      does not modify it's TC configuration by calling appropriate AQ command
      believing it is running with the same configuration as requested.
      Now, as the VEB is not actually enabled for the TCs that are there any
      TC configuration command for VSI attached to that VEB with TCs that are
      not enabled for the VEB fails.
      
      This patch fixes this issue.
      
      Change-ID: Ife5694469b05494228e0d850429ea1734738cf29
      Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
      Tested-By: NJack Morgan <jack.morgan@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      23cd1f09