On Wed, Nov 30, 2016 at 05:01:32PM +0000, Liran Liss wrote: > > 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 Each ib_device is either iwarp or rocee, the rdma cm would route iwarp stuff to the iwarp one and rocee stuff to the rocee one. Not really a problem with today's architecture. > - this doesn't change anything. Also, AHs are already > port-specific. So, I don't see any issue in this regard. The current scheme infers the protocol of the AH from the current configuration of the port, which is a crazy API when the port's protocol can change on the fly. > 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. Of course we can change how they are modeled in Linux, it is just software. > 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. Perhaps a moritorium on some changes to the current uAPI will encourage the new one to get finished :P 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
