> > 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
