RE: [PATCH v5 00/27] IB/Verbs: IB Management Helpers

[Liran Liss]

> From: Hefty, Sean [mailto:sean.hefty@xxxxxxxxx]

[snip]
> > > So, I think that our "old-transport" below is just fine.
> > > No need to change it (and you aren't, since it is currently
> > > implemented
> > as a function).
> >
> > I think there is a need to change this.  Encoding the transport into
> > the node type is not a good idea.  Having different "transport
> > semantics" while still returning the same transport for the port is
> > confusing.
> >
> > The only thing which is clear currently is Link Layer.
> >
> > But the use of "Link Layer" in the code is so convoluted that it is
> > very confusing.
> 
> I agree.
> 
> One could implement software iWarp or IBoUDP (RoCEv2) protocols that
> could run over any link layer and interoperate with existing HW solutions.
> The stack shouldn't be dealing with the link level at all, with the exception of
> user space compatibility.
> 
> > Define Transport?  There has been a lot of discussion over what a
> > transport is in Verbs.
> 
> IMO, we should replace using the word 'transport' with just 'rdma_protocol'.
> And even then I'm not convinced that anything should care, beyond user
> space compatibility.  The caps are what matter.
> 
> - Sean

I completely agree.
If we ever see a need for representing a set or subset of cross-layer protocols (at any level, L2-L4, various encapsulations), we will add the proper management helpers.
For example:
- rdma_protocol_roce() /* both v1 and v2 */
- rdma_protocol_roce_v1()
- rdma_protocol_roce_v2()
- rdma_protocol_usnic()
- rdma_protocol_usnic_udp()