On Mon, Dec 5, 2016 at 10:14 PM, Liran Liss <liranl@xxxxxxxxxxxx> wrote: >> From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] >>> Anyway, returning to the initial matter at hand: I would like to start >>> with each port reporting a bit mask of the supported protocols on that >>> link (RoCE v1/v2, Raw Ethernet, iWARP, etc.) It will be used for >>> reporting device capabilities in general for tools, as well as by >>> applications that don't use rdmacm. >> Why don't we start by defining how it is supposed to even work and how to fix >> the RDMA CM before adding even more random capability bits? > Extensions to RDMA CM is an important topic, which we can continue to discuss as devices that require it are introduced. > Protocol capabilities are needed for information purposes as well as for applications that do not use RDMA CM. > They are not "random", but depict what a device can do. Doug, Can we get a maintainer say here? I didn't see complaints on the mlx5 IB driver patch that opens IB device also in the lack of RoCE support. We have a valid real life use-case which needs this driver patch. Per your request, I made also some core patch to expose QPTs to user-space and we went into this long discussion. Do you want the change along what was proposed by Liran (allow user-space to query the supported protocols per port) or you are okay with taking only the mlx5 patches for now and discuss the rest later or something else? Please let us know Or. -- 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
