1. 19 8月, 2017 1 次提交
  2. 12 8月, 2017 1 次提交
    • S
      nfp: do not update MTU from BH in flower app · bb3afda4
      Simon Horman 提交于
      The Flower app may receive a request to update the MTU of a representor
      netdev upon receipt of a control message from the firmware. This requires
      the RTNL lock which needs to be taken outside of the packet processing
      path.
      
      As a handling of this correctly seems a little to invasive for a fix simply
      skip setting the MTU for now.
      
      Relevant backtrace:
       [ 1496.288489] BUG: scheduling while atomic: kworker/0:3/373/0x00000100
       [ 1496.294911]  dca syscopyarea sysfillrect sysimgblt fb_sys_fops ptp drm mxm_wmi ahci pps_core libahci i2c_algo_bit wmi [last unloaded: nfp]
       [ 1496.294918] CPU: 0 PID: 373 Comm: kworker/0:3 Tainted: G           OE   4.13.0-rc3+ #3
       [ 1496.294919] Hardware name: Supermicro X10DRi/X10DRi, BIOS 2.0 12/28/2015
       [ 1496.294923] Workqueue: events work_for_cpu_fn
       [ 1496.294924] Call Trace:
       [ 1496.294927]  <IRQ>
       [ 1496.294931]  dump_stack+0x63/0x82
       [ 1496.294935]  __schedule_bug+0x54/0x70
       [ 1496.294937]  __schedule+0x62f/0x890
       [ 1496.294941]  ? intel_unmap_sg+0x90/0x90
       [ 1496.294942]  schedule+0x36/0x80
       [ 1496.294943]  schedule_preempt_disabled+0xe/0x10
       [ 1496.294945]  __mutex_lock.isra.2+0x445/0x4a0
       [ 1496.294947]  ? device_is_rmrr_locked+0x12/0x50
       [ 1496.294950]  ? kfree+0x162/0x170
       [ 1496.294952]  ? device_is_rmrr_locked+0x12/0x50
       [ 1496.294953]  ? iommu_should_identity_map+0x50/0xe0
       [ 1496.294954]  __mutex_lock_slowpath+0x13/0x20
       [ 1496.294955]  ? iommu_no_mapping+0x48/0xd0
       [ 1496.294956]  ? __mutex_lock_slowpath+0x13/0x20
       [ 1496.294957]  mutex_lock+0x2f/0x40
       [ 1496.294960]  rtnl_lock+0x15/0x20
       [ 1496.294979]  nfp_flower_cmsg_rx+0xc8/0x150 [nfp]
       [ 1496.294986]  nfp_ctrl_poll+0x286/0x350 [nfp]
       [ 1496.294989]  tasklet_action+0xf6/0x110
       [ 1496.294992]  __do_softirq+0xed/0x278
       [ 1496.294993]  irq_exit+0xb6/0xc0
       [ 1496.294994]  do_IRQ+0x4f/0xd0
       [ 1496.294996]  common_interrupt+0x89/0x89
      
      Fixes: 948faa46 ("nfp: add support for control messages for flower app")
      Signed-off-by: NSimon Horman <simon.horman@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb3afda4
  3. 02 8月, 2017 1 次提交
  4. 12 7月, 2017 1 次提交
  5. 07 7月, 2017 1 次提交
  6. 05 7月, 2017 3 次提交
    • J
      nfp: default to chained metadata prepend format · 64a919a9
      Jakub Kicinski 提交于
      ABI 4.x introduced the chained metadata format and made it the
      only one possible.  There are cases, however, where the old
      format is preferred - mostly to make interoperation with VFs
      using ABI 3.x easier for the datapath.  In ABI 5.x we allowed
      for more flexibility by selecting the metadata format based
      on capabilities.  The default was left to non-chained.
      
      In case of fallback traffic, there is no capability telling the
      driver there may be chained metadata.  With a very stripped-
      -down FW the default old metadata format would be selected
      making the driver drop all fallback traffic.
      
      This patch changes the default selection in the driver. It
      should not hurt with old firmwares, because if they don't
      advertise RSS they will not produce metadata anyway.  New
      firmwares advertising ABI 5.x, however, can depend on the
      driver defaulting to chained format.
      
      Fixes: f9380629 ("nfp: advertise support for NFD ABI 0.5")
      Suggested-by: NMichael Rapson <michael.rapson@netronome.com>
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64a919a9
    • J
      nfp: remove legacy MAC address lookup · cb2cda48
      Jakub Kicinski 提交于
      The legacy MAC address lookup doesn't work well with breakout
      cables.  We are probably better off picking random addresses
      than the wrong ones in the theoretical scenario where management
      FW didn't tell us what the port config is.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb2cda48
    • J
      nfp: improve order of interfaces in breakout mode · 2eb333c4
      Jakub Kicinski 提交于
      For historical reasons we enumerate the vNICs in order.  This means
      that if user configures breakout on a multiport card, the first
      interface of the second port will have its MAC address changed.
      
      What's worse, when moved from static information (HWInfo) to using
      management FW (NSP), more features started depending on the port ids.
      Right now in case of breakout first subport of the second port and
      second subport of the first port will have their link info swapped.
      
      Revise the ordering scheme so that first subport maintains its address.
      Side effect of this change is that we will use base lane ids in
      devlink (i.e. 40G ports will be 4 ids apart), e.g.:
      
      pci/0000:04:00.0/0: type eth netdev p6p1
      pci/0000:04:00.0/4: type eth netdev p6p2
      
      Note that behaviour of phys_port_id is not changed since there is
      a separate id number for the subport there.
      
      Fixes: ec8b1fbe ("nfp: support port splitting via devlink")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2eb333c4
  7. 01 7月, 2017 8 次提交
  8. 28 6月, 2017 14 次提交
  9. 25 6月, 2017 10 次提交