1. 29 4月, 2020 6 次提交
  2. 24 4月, 2020 1 次提交
  3. 19 4月, 2020 1 次提交
  4. 27 3月, 2020 2 次提交
  5. 25 3月, 2020 2 次提交
    • M
      RDMA/mlx5: Block delay drop to unprivileged users · ba80013f
      Maor Gottlieb 提交于
      It has been discovered that this feature can globally block the RX port,
      so it should be allowed for highly privileged users only.
      
      Fixes: 03404e8a("IB/mlx5: Add support to dropless RQ")
      Link: https://lore.kernel.org/r/20200322124906.1173790-1-leon@kernel.orgSigned-off-by: NMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      ba80013f
    • L
      RDMA/mlx5: Fix access to wrong pointer while performing flush due to error · 950bf4f1
      Leon Romanovsky 提交于
      The main difference between send and receive SW completions is related to
      separate treatment of WQ queue. For receive completions, the initial index
      to be flushed is stored in "tail", while for send completions, it is in
      deleted "last_poll".
      
        CPU: 54 PID: 53405 Comm: kworker/u161:0 Kdump: loaded Tainted: G           OE    --------- -t - 4.18.0-147.el8.ppc64le #1
        Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
        NIP:  c000003c7c00a000 LR: c00800000e586af4 CTR: c000003c7c00a000
        REGS: c0000036cc9db940 TRAP: 0400   Tainted: G           OE    --------- -t -  (4.18.0-147.el8.ppc64le)
        MSR:  9000000010009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 24004488  XER: 20040000
        CFAR: c00800000e586af0 IRQMASK: 0
        GPR00: c00800000e586ab4 c0000036cc9dbbc0 c00800000e5f1a00 c0000037d8433800
        GPR04: c000003895a26800 c0000037293f2000 0000000000000201 0000000000000011
        GPR08: c000003895a26c80 c000003c7c00a000 0000000000000000 c00800000ed30438
        GPR12: c000003c7c00a000 c000003fff684b80 c00000000017c388 c00000396ec4be40
        GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR20: c00000000151e498 0000000000000010 c000003895a26848 0000000000000010
        GPR24: 0000000000000010 0000000000010000 c000003895a26800 0000000000000000
        GPR28: 0000000000000010 c0000037d8433800 c000003895a26c80 c000003895a26800
        NIP [c000003c7c00a000] 0xc000003c7c00a000
        LR [c00800000e586af4] __ib_process_cq+0xec/0x1b0 [ib_core]
        Call Trace:
        [c0000036cc9dbbc0] [c00800000e586ab4] __ib_process_cq+0xac/0x1b0 [ib_core] (unreliable)
        [c0000036cc9dbc40] [c00800000e586c88] ib_cq_poll_work+0x40/0xb0 [ib_core]
        [c0000036cc9dbc70] [c000000000171f44] process_one_work+0x2f4/0x5c0
        [c0000036cc9dbd10] [c000000000172a0c] worker_thread+0xcc/0x760
        [c0000036cc9dbdc0] [c00000000017c52c] kthread+0x1ac/0x1c0
        [c0000036cc9dbe30] [c00000000000b75c] ret_from_kernel_thread+0x5c/0x80
      
      Fixes: 8e3b6883 ("RDMA/mlx5: Delete unreachable handle_atomic code by simplifying SW completion")
      Link: https://lore.kernel.org/r/20200318091640.44069-1-leon@kernel.orgSigned-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      950bf4f1
  6. 05 3月, 2020 1 次提交
  7. 12 2月, 2020 1 次提交
  8. 17 1月, 2020 1 次提交
  9. 16 1月, 2020 2 次提交
    • M
      IB/mlx5: Add ODP WQE handlers for kernel QPs · da9ee9d8
      Moni Shoua 提交于
      One of the steps in ODP page fault handler for WQEs is to read a WQE
      from a QP send queue or receive queue buffer at a specific index.
      
      Since the implementation of this buffer is different between kernel and
      user QP the implementation of the handler needs to be aware of that and
      handle it in a different way.
      
      ODP for kernel MRs is currently supported only for RDMA_READ
      and RDMA_WRITE operations so change the handler to
      - read a WQE from a kernel QP send queue
      - fail if access to receive queue or shared receive queue is
        required for a kernel QP
      Signed-off-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      da9ee9d8
    • M
      IB: Allow calls to ib_umem_get from kernel ULPs · c320e527
      Moni Shoua 提交于
      So far the assumption was that ib_umem_get() and ib_umem_odp_get()
      are called from flows that start in UVERBS and therefore has a user
      context. This assumption restricts flows that are initiated by ULPs
      and need the service that ib_umem_get() provides.
      
      This patch changes ib_umem_get() and ib_umem_odp_get() to get IB device
      directly by relying on the fact that both UVERBS and ULPs sets that
      field correctly.
      Reviewed-by: NGuy Levi <guyle@mellanox.com>
      Signed-off-by: NMoni Shoua <monis@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      c320e527
  10. 04 1月, 2020 1 次提交
  11. 20 11月, 2019 1 次提交
  12. 17 11月, 2019 1 次提交
  13. 01 11月, 2019 1 次提交
    • M
      IB/mlx5: Test write combining support · 11f552e2
      Michael Guralnik 提交于
      Linux can run in all sorts of physical machines and VMs where write
      combining may or may not be supported. Currently there is no way to
      reliably tell if the system supports WC, or not. The driver uses WC to
      optimize posting work to the HCA, and getting this wrong in either
      direction can cause a significant performance loss.
      
      Add a test in mlx5_ib initialization process to test whether
      write-combining is supported on the machine.  The test will run as part of
      the enable_driver callback to ensure that the test runs after the device
      is setup and can create and modify the QP needed, but runs before the
      device is exposed to the users.
      
      The test opens UD QP and posts NOP WQEs, the WQE written to the BlueFlame
      is different from the WQE in memory, requesting CQE only on the BlueFlame
      WQE. By checking whether we received a completion on one of these WQEs we
      can know if BlueFlame succeeded and this write-combining must be
      supported.
      
      Change reporting of BlueFlame support to be dependent on write-combining
      support instead of the FW's guess as to what the machine can do.
      
      Link: https://lore.kernel.org/r/20191027062234.10993-1-leon@kernel.orgSigned-off-by: NMichael Guralnik <michaelgur@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      11f552e2
  14. 23 10月, 2019 1 次提交
  15. 18 10月, 2019 1 次提交
  16. 21 8月, 2019 1 次提交
  17. 29 7月, 2019 1 次提交
  18. 25 7月, 2019 2 次提交
  19. 05 7月, 2019 1 次提交
  20. 04 7月, 2019 1 次提交
  21. 24 6月, 2019 8 次提交
  22. 21 6月, 2019 2 次提交
  23. 03 5月, 2019 1 次提交
    • J
      IB/mlx5: Add missing XRC options to QP optional params mask · 8f4426aa
      Jack Morgenstein 提交于
      The QP transition optional parameters for the various transition for XRC
      QPs are identical to those for RC QPs.
      
      Many of the XRC QP transition optional parameter bits are missing from the
      QP optional mask table.  These omissions caused failures when doing XRC QP
      state transitions.
      
      For example, when trying to change the response timer of an XRC receive QP
      via the RTS2RTS transition, the new timer value was ignored because
      MLX5_QP_OPTPAR_RNR_TIMEOUT bit was missing from the optional params mask
      for XRC qps for the RTS2RTS transition.
      
      Fix this by adding the missing XRC optional parameters for all QP
      transitions to the opt_mask table.
      
      Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters")
      Fixes: a4774e90 ("IB/mlx5: Fix opt param mask according to firmware spec")
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      8f4426aa