Messages in this thread | | | From | Liran Liss <> | Subject | RE: [PATCH v5 00/27] IB/Verbs: IB Management Helpers | Date | Fri, 24 Apr 2015 14:49:49 +0000 |
| |
> From: Hefty, Sean [mailto:sean.hefty@intel.com]
[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()
| |