On Fri, 2015-05-08 at 20:06 +0000, Hefty, Sean wrote:
> > This is what I have so far:
> >
> > On a per device basis: not much to be honest, node_type IB_CA/RNIC for
> > back compatibility and that's pretty much it
> >
> > On a per port basis: link layer (Ethernet, IB, or OPA). Notice that I
> > didn't include the transport here. Two of the above link layers
> > strictly imply their transport. The third link layer could have
> > multiple transports. Which brings me to my next level...
> >
> > On a per queue pair basis: if (link_layer == Ethernet) iWARP/RoCE/USNIC
> > if (qp_type == RoCE && qp != UD) RoCEv1/RoCEv2
> >
> > On a per ah basis: if (qp_type == RoCE && qp = UD) RoCEv1/RoCEv2
> >
> > Michael's patch set was intended to give us a framework within which we
> > can start cleaning things up. Once we get to cleaning things up, I
> > think the above is where we should target storing the relevant
> > information.
> >
> > Thoughts?
>
> I'm not following your intent here.
>
> The qp_type values are currently defined as RC, UC, UD, XRC, plus some
> weirdness like SMI, GSI. Are you suggesting that we store the relevant
> information as part of the qp_type, or that we keep the qp_type as-is?
Well, you note I wrote qp != UD, where as that's really the qp_type, so
the above was psuedo code at best. I was necessarily suggesting where
in the qp data struct to store it, just that even though there isn't
hardware that does this (yet), there's no reason hardware couldn't be
designed to support both iWARP and RoCE and USNIC over the same Ethernet
link layer, and merging the SoftRoCE and SoftiWARP drivers would make a
proof of concept, and so we would *have* to store that information on a
per QP basis.
>
Once Michael's patches are integrated, do apps need anything else
> beyond the qp type as currently defined?
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.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: 0E572FDD
Attachment:
signature.asc
Description: This is a digitally signed message part
