Implementing RoCEv2

[Skinbow]

This PR adds RoCEv2 (RDMA over Converged Ethernet v2 with RDMA being Remote Direct Memory Access) functionality to LiteEth.

In particular, this pull request is built to be compliant with the InfiniBand Architecture Specification Volume 1 (Release 1.2.1).
It implements the Transport Layer (Chapter 9) of the InfiniBand protocol as well as the CM (Communication Management) protocol (Chapter 12) and part of the IP CM protocol (Annex A11) for standard connection establishment.
This is done on top of the UDP/IP (similarly to the LiteEthUDPIPCore) to comply with the Annex 17 - RoCEv2 of the InfiniBand specification.

The changes are gathered in the LiteEthRoCEv2Core which includes the RDMA on top of the IP/UDP stack (which remains usable for normal UDP connections through ports other than 4791, which is the IANA assigned port for the RoCEv2 protocol).

Both the responder and requester side of the protocol is implemented, meaning that the FPGA can function as the passive or active TCA (Target Channel Adapter) which can have one QP (Queue Pair) in RC (Reliable Connection) mode, as well as a Special QP (QP1) used for CM in UD (Unreliable Datagram) mode.

Only the responder side of the CM protocol is implemented here, so the connection establishment must be done by the other device.

Thus, an HCA (Host Channel Adapter) can establish a connection and send RDMA Read and Write operations, as well as Send operations to this module, and receive acknowledgements as specified in the protocol. Additionally, the module can send RDMA Read and Write requests as well as Send requests, to which the HCA has to respond. This allows existing hardware such as Mellanox ConnectX cards to communicate with the FPGA through the use of Infiniband's Verbs API as well as other calls to the rdma-core library. Regular networking cards can also communicate through RoCEv2 with Software ROCE, also implemented in the rdma-core library.

Note that for the FPGA to be the requester in this connection, for it to send RDMA requests, the HCA has to transfer its memory regions' keys to the FPGA. The way of doing this is not specified in the protocol. The LiteEthKeyExchanger module shows an example of how it can be done.

Tests

This module has been tested using a 1000BASE-T and 1000BASE-LX connection to a Mellanox ConnectX-4 Lx, as well as a regular networking card using Software ROCE.

It can be tested using the test.c script I am sharing through this gist.

Here are some tests results that I obtained with the Mellanox card:

Test of a RDMA_WRITE followed by an RDMA READ on the same memory region (twice):

$ ./test -C 2 -c -a 192.170.1.50 -S 32 -V
Sent:
\x05\x0c\xd4\x74\xe5\xd3\x27\x44\x45\x64\x29\x56\x09\x49\x69\x46\x39\x80\xcc\x48\xd5\x1b\xf0\xce\xf3\xe4\x7a\x95\x02\x79\x37\xf8
Received:
\x05\x0c\xd4\x74\xe5\xd3\x27\x44\x45\x64\x29\x56\x09\x49\x69\x46\x39\x80\xcc\x48\xd5\x1b\xf0\xce\xf3\xe4\x7a\x95\x02\x79\x37\xf8

Data matches
Sent:
\xdc\xc2\x6b\x56\x2b\x8f\xe9\x2b\x60\x63\x9b\xf0\xd0\x58\x2f\x28\x1d\x3b\xd0\xe1\xf3\xc6\xe1\x09\x68\xc9\x2b\xc3\xc8\xc9\x8b\x44
Received:
\xdc\xc2\x6b\x56\x2b\x8f\xe9\x2b\x60\x63\x9b\xf0\xd0\x58\x2f\x28\x1d\x3b\xd0\xe1\xf3\xc6\xe1\x09\x68\xc9\x2b\xc3\xc8\xc9\x8b\x44

Data matches

with the transmission showing in Wireshark:

Benchmarks with RDMA_WRITEs:

$ ./test -b -w -C 1000 -c -a 192.170.1.50 -S 1024
Sent 8 1024-byte RDMA_WRITEs 1000 times in 71.88ms
This amounts to a transfer rate of MB/s: 113.962990
$ ./test -b -w -C 1000 -c -a 192.170.1.50 -S 2048
Sent 8 2048-byte RDMA_WRITEs 1000 times in 142.63ms
This amounts to a transfer rate of MB/s: 114.872999
$ ./test -b -w -C 1000 -c -a 192.170.1.50 -S 32768
Sent 8 32768-byte RDMA_WRITEs 1000 times in 2.27s
This amounts to a transfer rate of MB/s: 115.677083

Benchmarks with RDMA_READs

$ ./test -b -r -C 1000 -c -a 192.170.1.50 -S 1024
Sent 8 1024-byte RDMA_READs 1000 times in 71.22ms
This amounts to a transfer rate of MB/s: 115.028594
$ ./test -b -r -C 1000 -c -a 192.170.1.50 -S 2048
Sent 8 2048-byte RDMA_READs 1000 times in 142.70ms
This amounts to a transfer rate of MB/s: 114.817430
$ ./test -b -r -C 1000 -c -a 192.170.1.50 -S 32768
Sent 8 32768-byte RDMA_READs 1000 times in 2.27s
This amounts to a transfer rate of MB/s: 115.701172

Benchmarks with RDMA_READs and RDMA_WRITEs in quick succession:

$ ./test -b -rw -C 1000 -c -a 192.170.1.50 -S 2048 -B
Sent 8 2048-byte RDMA_WRITEs and RDMA_READs 1000 times in 76.81ms
This amounts to a bidirectional transfer rate of MB/s: 213.298131

Related changes

This pull request relies on a couple of changes throughout the LiteX, such as an additional last signal in the LiteDRAMDMAWriter of LiteDRAM's frontend/dma.py (see "Added last signal to LiteDRAMWriter#377").
It also relies on a small change to the Header class in LiteX's soc/interconnect/packet.py (see "Allow for changing starting position of header#2441").

[Skinbow]

Added new changes (More versatile memory regions) and rebased on master + some minor bug fixes.
Plus made some additional effort to close timings.