-----"Tom Talpey" <tom@xxxxxxxxxx> wrote: ----- >To: "Jason Gunthorpe" <jgg@xxxxxxxx>, "Bernard Metzler" ><BMT@xxxxxxxxxxxxxx> >From: "Tom Talpey" <tom@xxxxxxxxxx> >Date: 02/19/2021 03:15PM >Cc: "Chuck Lever" <chuck.lever@xxxxxxxxxx>, "linux-rdma" ><linux-rdma@xxxxxxxxxxxxxxx>, "Benjamin Coddington" ><bcodding@xxxxxxxxxx> >Subject: [EXTERNAL] Re: directing soft iWARP traffic through a secure >tunnel > >On 2/19/2021 8:57 AM, Jason Gunthorpe wrote: >> On Fri, Feb 19, 2021 at 01:06:26PM +0000, Bernard Metzler wrote: >> >>> 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 >> if the gid table code has gained general rocee behaviors that are >not >> 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. > > >> 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.
