> Existing apps rely on transport_type == IBV_TRANSPORT_IB to indicate IB management is present. There are many examples of this. > The art of API compatability is to not break existing old apps, so you don't get to change the meaning of transport_type == IBV_TRANSPORT_IB to mean 'it is only IB verbs like'. That breaks the API. > Adding a new field to port_attr preserves functionality but not compatability. I hope you understand the difference.
I understand exactly what you mean, but I want to propose another way of looking at the compatibility issue: IB management is a network service. Just as an administrator might mistakenly try to access an FTP server over a wrong eth interface, an IB admin can mistakenly run an IB management application (or a non-rdmacm app that is incompatible with RDMAoE) on a RDMAoE port. In both cases, the service is unreachable, but otherwise no harm is done. Basically, IB management is "supported" by RDMAoE --- you use the same verbs to access it but you don't get any answers... (Of course that it terms of implementation, we can choose to drop SMPs or non-CM MADs rather then sending them on the wire.) There is a tradeoff here between transparently supporting existing rdmacm apps versus making sure that non-rdmacm apps that may come across an RDMAoE port do not attempt to use it. Given the fact that rdmacm has become a preferred approach, and that for non-rdmacm apps the worst case effect is that of being unable to create a connection through a port that they were not designed to support to begin with, we prefer the approach that we proposed. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
