1. 12 12月, 2014 8 次提交
    • D
      net/mlx4: Add a check if there are too many reserved QPs · ab256e5a
      Dotan Barak 提交于
      The number of reserved QPs is affected both from the firmware and
      from the driver's requirements. This patch adds a check that
      validates that this number is indeed feasable.
      Signed-off-by: NDotan Barak <dotanb@dev.mellanox.co.il>
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab256e5a
    • E
      net/mlx4: Change QP allocation scheme · ddae0349
      Eugenia Emantayev 提交于
      When using BF (Blue-Flame), the QPN overrides the VLAN, CV, and SV fields
      in the WQE. Thus, BF may only be used for QPNs with bits 6,7 unset.
      
      The current Ethernet driver code reserves a Tx QP range with 256b alignment.
      
      This is wrong because if there are more than 64 Tx QPs in use,
      QPNs >= base + 65 will have bits 6/7 set.
      
      This problem is not specific for the Ethernet driver, any entity that
      tries to reserve more than 64 BF-enabled QPs should fail. Also, using
      ranges is not necessary here and is wasteful.
      
      The new mechanism introduced here will support reservation for
      "Eth QPs eligible for BF" for all drivers: bare-metal, multi-PF, and VFs
      (when hypervisors support WC in VMs). The flow we use is:
      
      1. In mlx4_en, allocate Tx QPs one by one instead of a range allocation,
         and request "BF enabled QPs" if BF is supported for the function
      
      2. In the ALLOC_RES FW command, change param1 to:
      a. param1[23:0]  - number of QPs
      b. param1[31-24] - flags controlling QPs reservation
      
      Bit 31 refers to Eth blueflame supported QPs. Those QPs must have
      bits 6 and 7 unset in order to be used in Ethernet.
      
      Bits 24-30 of the flags are currently reserved.
      
      When a function tries to allocate a QP, it states the required attributes
      for this QP. Those attributes are considered "best-effort". If an attribute,
      such as Ethernet BF enabled QP, is a must-have attribute, the function has
      to check that attribute is supported before trying to do the allocation.
      
      In a lower layer of the code, mlx4_qp_reserve_range masks out the bits
      which are unsupported. If SRIOV is used, the PF validates those attributes
      and masks out unsupported attributes as well. In order to notify VFs which
      attributes are supported, the VF uses QUERY_FUNC_CAP command. This command's
      mailbox is filled by the PF, which notifies which QP allocation attributes
      it supports.
      Signed-off-by: NEugenia Emantayev <eugenia@mellanox.co.il>
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddae0349
    • M
      net/mlx4_core: Use tasklet for user-space CQ completion events · 3dca0f42
      Matan Barak 提交于
      Previously, we've fired all our completion callbacks straight from our ISR.
      
      Some of those callbacks were lightweight (for example, mlx4_en's and
      IPoIB napi callbacks), but some of them did more work (for example,
      the user-space RDMA stack uverbs' completion handler). Besides that,
      doing more than the minimal work in ISR is generally considered wrong,
      it could even lead to a hard lockup of the system. Since when a lot
      of completion events are generated by the hardware, the loop over those
      events could be so long, that we'll get into a hard lockup by the system
      watchdog.
      
      In order to avoid that, add a new way of invoking completion events
      callbacks. In the interrupt itself, we add the CQs which receive completion
      event to a per-EQ list and schedule a tasklet. In the tasklet context
      we loop over all the CQs in the list and invoke the user callback.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3dca0f42
    • O
      net/mlx4_core: Mask out host side virtualization features for guests · 383677da
      Or Gerlitz 提交于
      When VFs (guests in this context) issue the QUERY_DEV_CAP command, they
      need not be told that host side virtualization features such as VST, FSM
      (MAC anti-spoofing) and running > 80 VFs are supported by the device.
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      383677da
    • O
      net/mlx4_en: Set csum level for encapsulated packets · c58942f2
      Or Gerlitz 提交于
      This was dropped by mistake for the napi_gro_frags flow, fix that.
      
      Fixes: dd65beac ('net/mlx4_en: Extend usage of napi_gro_frags')
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c58942f2
    • S
      be2net: Export tunnel offloads only when a VxLAN tunnel is created · 630f4b70
      Sriharsha Basavapatna 提交于
      The encapsulated offload flags shouldn't be unconditionally exported
      to the stack. The stack expects offloading to work across all tunnel
      types when those flags are set. This would break other tunnels (like
      GRE) since be2net currently supports tunnel offload for VxLAN only.
      
      Also, with VxLANs Skyhawk-R can offload only 1 UDP dport. If more
      than 1 UDP port is added, we should disable offloads in that case too.
      Signed-off-by: NSriharsha Basavapatna <sriharsha.basavapatna@emulex.com>
      Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      630f4b70
    • K
      gianfar: Fix dma check map error when DMA_API_DEBUG is enabled · 0a4b5a24
      Kevin Hao 提交于
      We need to use dma_mapping_error() to check the dma address returned
      by dma_map_single/page(). Otherwise we would get warning like this:
        WARNING: at lib/dma-debug.c:1140
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-rc2-next-20141029 #196
        task: c0834300 ti: effe6000 task.ti: c0874000
        NIP: c02b2c98 LR: c02b2c98 CTR: c030abc4
        REGS: effe7d70 TRAP: 0700   Not tainted  (3.18.0-rc2-next-20141029)
        MSR: 00021000 <CE,ME>  CR: 22044022  XER: 20000000
      
        GPR00: c02b2c98 effe7e20 c0834300 00000098 00021000 00000000 c030b898 00000003
        GPR08: 00000001 00000000 00000001 749eec9d 22044022 1001abe0 00000020 ef278678
        GPR16: ef278670 ef278668 ef278660 070a8040 c087f99c c08cdc60 00029000 c0840d44
        GPR24: c08be6e8 c0840000 effe7e78 ef041340 00000600 ef114e10 00000000 c08be6e0
        NIP [c02b2c98] check_unmap+0x51c/0x9e4
        LR [c02b2c98] check_unmap+0x51c/0x9e4
        Call Trace:
        [effe7e20] [c02b2c98] check_unmap+0x51c/0x9e4 (unreliable)
        [effe7e70] [c02b31d8] debug_dma_unmap_page+0x78/0x8c
        [effe7ed0] [c03d1640] gfar_clean_rx_ring+0x208/0x488
        [effe7f40] [c03d1a9c] gfar_poll_rx_sq+0x3c/0xa8
        [effe7f60] [c04f8714] net_rx_action+0xc0/0x178
        [effe7f90] [c00435a0] __do_softirq+0x100/0x1fc
        [effe7fe0] [c0043958] irq_exit+0xa4/0xc8
        [effe7ff0] [c000d14c] call_do_irq+0x24/0x3c
        [c0875e90] [c00048a0] do_IRQ+0x8c/0xf8
        [c0875eb0] [c000ed10] ret_from_except+0x0/0x18
      
      For TX, we need to unmap the pages which has already been mapped and
      free the skb before return.
      
      For RX, move the dma mapping and error check to gfar_new_skb(). We
      would reuse the original skb in the rx ring when either allocating
      skb failure or dma mapping error.
      Signed-off-by: NKevin Hao <haokexin@gmail.com>
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Reviewed-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a4b5a24
    • H
      cxgb4/csiostor: Don't use MASTER_MUST for fw_hello call · 666224d4
      Hariprasad Shenai 提交于
      Remove use of calls into t4_fw_hello() with MASTER_MUST, which results in
      FW_HELLO_CMD_MASTERFORCE being set. The firmware doesn't support this and of
      course any existing PF Drivers will totally go for a toss.
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      666224d4
  2. 11 12月, 2014 32 次提交