RE: [RFC PATCH 1/5] IB/core: Add Core Capability flags to ib_device

Liran Liss
2015-05-13T20:41:57Z

> From: Jason Gunthorpe [mailto:jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org]

> > > If you had a device that supported iWARP and RoCE on the same
> > > physical link layer, then yes, the app would need a means of saying
> > > which transport to use in addition to the type of QP to establish.
> >
> > Ah - got it now. And I agree, there should be some way to specify
> > this at the QP level.

Supporting iWARP and RoCE over the same RDMA device makes no sense.
First of all, it is confusing to the user. It's like supporting SRP and iSCSI
using the same SCSI device instance...

Second, different technologies affect much more than the QP.
A technology determines the format and semantics of the whole interface.
For example, AHs, memory windows, atomics, CQE formats are different as well.
Just thinking of how to abstract all these in single device is mind-boggling.

Finally, there is no sane way to describe device capabilities. There is no
single set of capabilities that applies to all of these technologies consistently.

>
> Yes, the only way out is to specify on a per QP basis the addressing and
> protocol/transport/whatever thing. Socket uses the AF,SOCK,PROTO tuple to
> specify this information. We can probably productively use a similar
> breakdown:

We might consider such abstractions at the CMA layer, not at the device level.
Essentially, this is what the CMA was intended for.

>
> AF_IB,SOCK_RC,PROTO_IBA // InfiniBand
> AF_OPA,SOCK_RC,PROTO_IBA // Future 32 bit LID OPB 'InfiniBand'

This is not PROTO_IBA.

> AF_ETH,SOCK_RC,PROTO_IBA // RoCEv1
> AF_INET,SOCK_RC,PROTO_IBA // InfiniBand or RoCEv2, depending on the Link
> Layer AF_ETH,SOCK_RC,PROTO_USNIC AF_INET,SOCK_RC,PROTO_USNIC
> AF_INET,SOCK_RC,PROTO_IWARP
>

[snip]
>
>
> Realistically, today, if a RoCE/iWarp driver appeared then it would have to
> present to the system as two RDMA devices.
>

Exactly!
--Liran