This sounds like it will work with existing TCP applications.

It's different. Rdma offloads the TCP transfer of host memory to the network device. This is about transferring device memory directly, avoiding going though the host.

Had to read through the lklm message, at it wasn't clear from the article.

RDMA does not offload TCP. Furthermore it's not limited to between NIC memories - for example GPU memory to remote GPU memory works as well.

From what I remember of Infiniband, the network cards are able to do direct PCIe transfers to/from compatible devices attached to the host (eg nvidia quadro gpus).

Specifically to avoid bogging down the host.

precisely this. The reason why its worth the expense is that data entering the network is guaranteed to come out the otherside. This kinda eliminates the need for TCP (apart from addressing)

This is my first thought, it sounds like inifiniband with with none of the guarantees.

I suppose it means that you can bust out of the local network, and take in "foreign" data. But if you're doing that, you've got bigger problems with data affinity.

Perhaps it's just avoiding the need to encapsulate an InfiniBand transport packet? I'm not sure how much overhead that introduces in RDMA, but DMTCP may just be an effort to divorce the idea from its original IB underpinnings.

RDMA is great and similar, but behaves very differently from TCP in the face of network congestion and longer distance traversals. This is essentially trying to get the best parts of TCP and the best parts of RDMA combined.

Wouldn’t that be RoCE? Or iWarp?

iWARP maybe, but I don't think you want to offload all of TCP to hardware. You want to leave congestion control and all that to software. I don't entirely know if that's why iWARP isn't very popular, but I suspect that's the reason. You want a software TCP stack that can land the data where you want it directly.