Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 1月, 2020 1 次提交
  3. 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
  5. 04 1月, 2020 1 次提交
  7. 20 11月, 2019 1 次提交
  9. 17 11月, 2019 1 次提交
  11. 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
  13. 23 10月, 2019 1 次提交
  15. 18 10月, 2019 1 次提交
  17. 21 8月, 2019 1 次提交
  19. 29 7月, 2019 1 次提交
  21. 25 7月, 2019 2 次提交
  23. 05 7月, 2019 1 次提交
  25. 04 7月, 2019 1 次提交
  27. 24 6月, 2019 8 次提交
  29. 21 6月, 2019 2 次提交
  31. 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
  33. 25 4月, 2019 1 次提交
  35. 18 4月, 2019 1 次提交
  37. 12 4月, 2019 1 次提交
  39. 11 4月, 2019 3 次提交
  41. 08 4月, 2019 1 次提交
    • W
      drivers: Remove explicit invocations of mmiowb() · fb24ea52
      由 Will Deacon 提交于 
      mmiowb() is now implied by spin_unlock() on architectures that require
it, so there is no reason to call it from driver code. This patch was
generated using coccinelle:

	@mmiowb@
	@@
	- mmiowb();

and invoked as:

$ for d in drivers include/linux/qed sound; do \
spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done

NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
spin_unlock(). However, pairing each mmiowb() removal in this patch with
the corresponding call to spin_unlock() is not at all trivial, so there
is a small chance that this change may regress any drivers incorrectly
relying on mmiowb() to order MMIO writes between CPUs using lock-free
synchronisation. If you've ended up bisecting to this commit, you can
reintroduce the mmiowb() calls using wmb() instead, which should restore
the old behaviour on all architectures other than some esoteric ia64
systems.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fb24ea52
  43. 03 4月, 2019 1 次提交
  45. 02 4月, 2019 3 次提交
  47. 28 3月, 2019 1 次提交
  49. 18 3月, 2019 1 次提交
  51. 16 2月, 2019 1 次提交