Merge branch 'wip/dl-for-next' into for-next

Due to concurrent work by myself and Jason, a normal fast forward merge
was not possible. This brings in a number of hfi1 changes, mainly the
hfi1 TID R

Merge branch 'wip/dl-for-next' into for-next

Due to concurrent work by myself and Jason, a normal fast forward merge
was not possible. This brings in a number of hfi1 changes, mainly the
hfi1 TID RDMA support (roughly 10,000 LOC change), which was reviewed
and integrated over a period of days.

Signed-off-by: Doug Ledford <dledford@redhat.com>

show more ...

Merge branch 'hfi1-tid' into wip/dl-for-next

Omni-Path TID RDMA Feature

Intel Omni-Path (OPA) TID RDMA support is a feature that accelerates
data movement between two OPA nodes through the IB Verbs

Merge branch 'hfi1-tid' into wip/dl-for-next

Omni-Path TID RDMA Feature

Intel Omni-Path (OPA) TID RDMA support is a feature that accelerates
data movement between two OPA nodes through the IB Verbs interface. It
improves RDMA READ/WRITE performance by delivering the data payload to a
user buffer directly without any software copying.

Architecture
=============
The TID RDMA protocol is implemented on the hfi1 driver level and is
therefore transparent to the ULPs. It is designed to facilitate the data
transactions for two specific RDMA requests:
- RDMA READ;
- RDMA WRITE.
Previously, when a verbs data packet is received at the destination
(requester side for RDMA READ and responder side for RDMA WRITE), the
data payload is copied to the user buffer by software, which slows down
the performance significantly for large requests.

Internally, hfi1 converts qualified RDMA READ/WRITE requests into TID
RDMA READ/WRITE requests when the requests are post sent to the hfi1
driver. Non-qualified RDMA requests are handled by normal RDMA protocol.

For TID RDMA requests, hardware resources (hardware flow and TID entries)
are allocated on the destination side (the requester side for TID RDMA
READ and the responder side for TID RDMA WRITE). The information for
these resources is conveyed to the data source side (the responder side
for TID RDMA READ and the requester side for TID RDMA WRITE) and embedded
in data packets. When data packets are received by the destination,
hardware will deliver the data payload to the destination buffer without
involving software and therefore improve the performance.

Details
=======
RDMA READ/WRITE requests are qualified by the following:
- Total data length >= 256k;
- Totoal data length is a multiple of 4K pages.

Additional qualifications are enforced for the destination buffers:
For RDMA RAED:
- Each destination sge buffer is 4K aligned;
- Each destination sge buffer is a multiple of 4K pages.
For RDMA WRITE:
- The destination number is 4K aligned.

In addition, in an OPA fabric, some nodes may support TID RDMA while
others may not. As such, it is important for two transaction nodes to
exchange the information about the features they support. This discovery
mechanism is called OPA Feature Negotion (OPFN) and is described in
details in the patch series. Through OPFN, two nodes can find whether
they both support TID RDMA and subsequently convert RDMA requests into
TID RDMA requests.

* hfi1-tid: (46 commits)
IB/hfi1: Prioritize the sending of ACK packets
IB/hfi1: Add static trace for TID RDMA WRITE protocol
IB/hfi1: Enable TID RDMA WRITE protocol
IB/hfi1: Add interlock between TID RDMA WRITE and other requests
IB/hfi1: Add TID RDMA WRITE functionality into RDMA verbs
IB/hfi1: Add the dual leg code
IB/hfi1: Add the TID second leg ACK packet builder
IB/hfi1: Add the TID second leg send packet builder
IB/hfi1: Resend the TID RDMA WRITE DATA packets
IB/hfi1: Add a function to receive TID RDMA RESYNC packet
IB/hfi1: Add a function to build TID RDMA RESYNC packet
IB/hfi1: Add TID RDMA retry timer
IB/hfi1: Add a function to receive TID RDMA ACK packet
IB/hfi1: Add a function to build TID RDMA ACK packet
IB/hfi1: Add a function to receive TID RDMA WRITE DATA packet
IB/hfi1: Add a function to build TID RDMA WRITE DATA packet
IB/hfi1: Add a function to receive TID RDMA WRITE response
IB/hfi1: Add TID resource timer
IB/hfi1: Add a function to build TID RDMA WRITE response
IB/hfi1: Add functions to receive TID RDMA WRITE request
...

Signed-off-by: Doug Ledford <dledford@redhat.com>

show more ...

Merge branch 'tid-write' into hfi1-tid

Here is the final set of patches for TID RDMA. Again this is code which
was previously submitted but re-organized so as to be easier to review.

Similar to how

Merge branch 'tid-write' into hfi1-tid

Here is the final set of patches for TID RDMA. Again this is code which
was previously submitted but re-organized so as to be easier to review.

Similar to how the READ series was organized the patches to build,
receive, allocate resources etc are broken out. For details on TID RDMA
as a whole again refer to the original cover letter.

https://www.spinics.net/lists/linux-rdma/msg66611.html

* tid-write: (23 commits)
IB/hfi1: Prioritize the sending of ACK packets
IB/hfi1: Add static trace for TID RDMA WRITE protocol
IB/hfi1: Enable TID RDMA WRITE protocol
IB/hfi1: Add interlock between TID RDMA WRITE and other requests
IB/hfi1: Add TID RDMA WRITE functionality into RDMA verbs
IB/hfi1: Add the dual leg code
IB/hfi1: Add the TID second leg ACK packet builder
IB/hfi1: Add the TID second leg send packet builder
IB/hfi1: Resend the TID RDMA WRITE DATA packets
IB/hfi1: Add a function to receive TID RDMA RESYNC packet
IB/hfi1: Add a function to build TID RDMA RESYNC packet
IB/hfi1: Add TID RDMA retry timer
IB/hfi1: Add a function to receive TID RDMA ACK packet
IB/hfi1: Add a function to build TID RDMA ACK packet
IB/hfi1: Add a function to receive TID RDMA WRITE DATA packet
IB/hfi1: Add a function to build TID RDMA WRITE DATA packet
IB/hfi1: Add a function to receive TID RDMA WRITE response
IB/hfi1: Add TID resource timer
IB/hfi1: Add a function to build TID RDMA WRITE response
IB/hfi1: Add functions to receive TID RDMA WRITE request
...

Signed-off-by: Doug Ledford <dledford@redhat.com>

show more ...

IB/hfi1: Prioritize the sending of ACK packets

ACK packets are generally associated with request completion and resource
release and therefore should be sent first. This patch optimizes the
send eng

IB/hfi1: Prioritize the sending of ACK packets

ACK packets are generally associated with request completion and resource
release and therefore should be sent first. This patch optimizes the
send engine by using the following policies:
(1) QPs with RVT_S_ACK_PENDING bit set in qp->s_flags or qpriv->s_flags
should have their priority incremented;
(2) QPs with ACK or TID-ACK packet queued should have their priority
incremented;
(3) When a QP is queued to the wait list due to resource constraints, it
will be queued to the head if it has ACK packet to send;
(4) When selecting qps to run from the wait list, the one with the highest
priority and starve_cnt will be selected; each priority will be equivalent
to a fixed number of starve_cnt (16).

Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>

show more ...

Merge tag 'v4.20' into for-linus

Sync with mainline to get linux/overflow.h among other things.

Merge tag 'v4.20' into next

Merge with mainline to bring in the new APIs.

Merge tag 'v4.20-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into fbdev-for-next

Linux 4.20-rc7

Sync with upstream (which now contains fbdev-v4.20 changes) to
prepare a b

Merge tag 'v4.20-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into fbdev-for-next

Linux 4.20-rc7

Sync with upstream (which now contains fbdev-v4.20 changes) to
prepare a base for fbdev-v4.21 changes.

show more ...

Merge drm/drm-next into drm-intel-next-queued

Pull in v4.20-rc3 via drm-next.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Merge remote-tracking branch 'drm/drm-next' into drm-misc-next

drm-next is forwarded to v4.20-rc1, and we need this to make
a patch series apply.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst

Merge remote-tracking branch 'drm/drm-next' into drm-misc-next

drm-next is forwarded to v4.20-rc1, and we need this to make
a patch series apply.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

show more ...

Merge tag 'v4.20-rc2' into next-general

Sync to Linux 4.20-rc2 for downstream developers.

Merge tag 'v4.20-rc1' into omap-for-v4.21/dt-ti-sysc

Linux 4.20-rc1

Merge branch 'fixes-dts' into omap-for-v4.20/fixes

Merge branch 'master' into for-4.20/upstream-fixes

Pull in a merge commit that brought in 3b692c55e58d ("HID: asus: only
support backlight when it's not driven by WMI") so that fixup could be
applie

Merge branch 'master' into for-4.20/upstream-fixes

Pull in a merge commit that brought in 3b692c55e58d ("HID: asus: only
support backlight when it's not driven by WMI") so that fixup could be
applied on top of it.

show more ...

Merge branch 'linus' into perf/urgent, to pick up fixes

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge branch 'linus' into x86/urgent, to refresh the tree

Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

Pull rdma updates from Jason Gunthorpe:
"This has been a smaller cycle with many of the commits being smallish
cod

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

Pull rdma updates from Jason Gunthorpe:
"This has been a smaller cycle with many of the commits being smallish
code fixes and improvements across the drivers.

- Driver updates for bnxt_re, cxgb4, hfi1, hns, mlx5, nes, qedr, and
rxe

- Memory window support in hns

- mlx5 user API 'flow mutate/steering' allows accessing the full
packet mangling and matching machinery from user space

- Support inter-working with verbs API calls in the 'devx' mlx5 user
API, and provide options to use devx with less privilege

- Modernize the use of syfs and the device interface to use attribute
groups and cdev properly for uverbs, and clean up some of the core
code's device list management

- More progress on net namespaces for RDMA devices

- Consolidate driver BAR mmapping support into core code helpers and
rework how RDMA holds poitners to mm_struct for get_user_pages
cases

- First pass to use 'dev_name' instead of ib_device->name

- Device renaming for RDMA devices"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (242 commits)
IB/mlx5: Add support for extended atomic operations
RDMA/core: Fix comment for hw stats init for port == 0
RDMA/core: Refactor ib_register_device() function
RDMA/core: Fix unwinding flow in case of error to register device
ib_srp: Remove WARN_ON in srp_terminate_io()
IB/mlx5: Allow scatter to CQE without global signaled WRs
IB/mlx5: Verify that driver supports user flags
IB/mlx5: Support scatter to CQE for DC transport type
RDMA/drivers: Use core provided API for registering device attributes
RDMA/core: Allow existing drivers to set one sysfs group per device
IB/rxe: Remove unnecessary enum values
RDMA/umad: Use kernel API to allocate umad indexes
RDMA/uverbs: Use kernel API to allocate uverbs indexes
RDMA/core: Increase total number of RDMA ports across all devices
IB/mlx4: Add port and TID to MAD debug print
IB/mlx4: Enable debug print of SMPs
RDMA/core: Rename ports_parent to ports_kobj
RDMA/core: Do not expose unsupported counters
IB/mlx4: Refer to the device kobject instead of ports_parent
RDMA/nldev: Allow IB device rename through RDMA netlink
...

show more ...

IB/hfi1: Add static trace for iowait

This patch adds the static trace for resource wait.

Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@i

IB/hfi1: Add static trace for iowait

This patch adds the static trace for resource wait.

Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>

show more ...

IB/hfi1: Prepare resource waits for dual leg

Current implementation allows each qp to have only one send engine. As
such, each qp has only one list to queue prebuilt packets when send engine
resour

IB/hfi1: Prepare resource waits for dual leg

Current implementation allows each qp to have only one send engine. As
such, each qp has only one list to queue prebuilt packets when send engine
resources are not available. To improve performance, it is desired to
support multiple send engines for each qp.

This patch creates the framework to support two send engines
(two legs) for each qp for the TID RDMA protocol, which can be easily
extended to support more send engines. It achieves the goal by creating a
leg specific struct, iowait_work in the iowait struct, to hold the
work_struct and the tx_list as well as a pointer to the parent iowait
struct.

The hfi1_pkt_state now has an additional field to record the current legs
work structure and that is now passed to all egress waiters to determine
the leg that needs to wait via a new iowait helper. The APIs are adjusted
to use the new leg specific struct as required.

Many new and modified helpers are added to support this change.

Reviewed-by: Mitko Haralanov <mitko.haralanov@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>

show more ...