RE: [PATCH v2 rdma-next 3/9] RDMA/nldev: provide detailed CM_ID information

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> 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.



--
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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux