-----"Tom Talpey" [off-list ref] wrote: -----

To: "Jason Gunthorpe" <jgg@ziepe.ca>, "Bernard Metzler"
[off-list ref]
From: "Tom Talpey" <tom@talpey.com>
Date: 02/19/2021 03:15PM
Cc: "Chuck Lever" <chuck.lever@oracle.com>, "linux-rdma"
[off-list ref], "Benjamin Coddington"
[off-list ref]
Subject: [EXTERNAL] Re: directing soft iWARP traffic through a secure
tunnel

On 2/19/2021 8:57 AM, Jason Gunthorpe wrote:

quoted

On Fri, Feb 19, 2021 at 01:06:26PM +0000, Bernard Metzler wrote:

quoted

Actually, all this GID and GUID and friends for iWARP
CM looks more like squeezing things into InfiniBand terms,
where we could just rely on plain ARP and IP
(ARP resolve interface, see if there is an RDMA device
bound to, done)... or do I miss something?

I don't know how iWarp cM works very well, it would not be

surprising

quoted

if the gid table code has gained general rocee behaviors that are

not

quoted

applicable to iwarp modes.

iWarp doesn't really need a CM, it is capable of peer-to-peer without
any need to assign connection and queuepair ID's. The CM
infrastructure
basically just implements a state machine to allow upper layers to
have
a consistent connection API.

Well hardware iWarp need someone to organize taking away ports
from kernel TCP which are bound to RNIC's.

I'm with Bernard here, forcing iWarp to use CM is a fairly unnatural
act. Assigning a GID/GUID is unnecessary from a protocol perspective.

quoted

With Steve gone I don't think there is really anyone left that even
really knows how the iWarp stuff works??

Cleaning up the iWarp path of it might be a complex undertaking.
I don't think going down that path solves the issue soon enough
for NFS/RDMA folks. But I will spend some time trying to wrap
my head around it...

Best,
Bernard.