> > > > > On Mon, Feb 19, 2018 at 05:11:52PM -0600, Steve Wise wrote: > > > > > > > > > + /* > > > > > + * ARPHRD_INFINIBAND, ARPHRD_ETHER, ... > > > > > + */ > > > > > + RDMA_NLDEV_ATTR_RES_DEV_TYPE, /* u8 */ > > > > > + /* > > > > > + * enum enum rdma_transport_type (IB, IWARP, ...) > > > > > + */ > > > > > + RDMA_NLDEV_ATTR_RES_TRANSPORT_TYPE, /* u8 */ > > > > > + /* > > > > > + * enum rdma_network_type (IB, IPv4, IPv6,...) > > > > > + */ > > > > > + RDMA_NLDEV_ATTR_RES_NETWORK_TYPE, /* u8 */ > > > > > > > > All of these enums are in a uapi header someplace, right? > > > > > > Yes. Include/uapi/rdma/rdma_netlink.h > > > > I mean the enums mentioned in the comments.. > > Ah. Perhaps not. Yea, they should be moved to the uapi. > > > > > > > Not sure I like this - why so many ways to say almost the same thing? > > > > > > I simply took the approach to add a NLDEV type for each field being > passed > > > up. That allows the user mode tool to parse the types into human- > > readable > > > format. IE it will know what the valid values are for dev_type, > > > transport_type, etc... Similar to what is there already for the qp > > > resource. > > > > It does seem like overkill though.. > > > > It is all part of the logic to detect RoCEv1 vs RoCEv2 vs IB proper, I > think. It is confusing. > > > Are these in the CM_ID or just new device attributes? > > > > They're actually in struct rdma_dev_addr, which is part of a cm_id... > > Steve. > I'm going to remove these attrs. I think it should be obvious what they are for a given cmid based on the device it is using. Steve. -- 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
