> From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] > > > Exactly. If/when such devices appear, we would need to extend > > connection management to specify the protocol, rather than infer it > > from the port space. > > We support that perfectly today as long as the port creates two 'struct > ib_devices'. Anything else will require some kind of changes to libibverb's API to > specify the AH style. > rdmacm would still have to choose between these ib_devices somehow - this doesn't change anything. Also, AHs are already port-specific. So, I don't see any issue in this regard. In any case, we have millions of multi-port devices that can use different link types deployed. This is the specification, and more such devices could appear in the future. We cannot change the device model. > > Rethinking about the uAPI, maybe we should report a protocol bit-mask > > similar to the kernel's, instead of QP types? This would provide all > > the required information (e.g., any combination of RoCEv1/v2, iWARP, > > and Raw Ethernet for Ethernet links) for today's use-cases as well as > > tomorrow's combined RoCE/iWARP devices. > > Maybe we should dump this uapi stuff until Matan's patches are done. The > introspection possible with Matan's work is flexible enough to cope with more > cases.. No doubt that the new ABI would be a lot more flexible and self-describing. But it would take a while until we port everything to use it. So, generally, I don't see any problem using the current extensibility capabilities to support useful semantics. > > Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
