> From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, July 06, 2015 4:59 PM > To: Wan, Kaike > Cc: linux-rdma@xxxxxxxxxxxxxxx; Fleck, John; Weiny, Ira > Subject: Re: [PATCH v7 1/4] IB/netlink: Add defines for local service requests > through netlink > > > > > +/* Local service status attribute */ enum { > > > > + LS_NLA_STATUS_SUCCESS = 0, > > > > + LS_NLA_STATUS_EINVAL, > > > > + LS_NLA_STATUS_ENODATA, > > > > + LS_NLA_STATUS_MAX > > > > +}; > > > > > > So, this is never used, there seems to be a bunch of never used > > > stuff > > > - please audit everything and get rid of the cruft before re-sending > anything. > > > > Well, EINVAL and ENODATA are not used by the kernel, but used by the > > application (ibacm). Should this file > > (include/uapi/rdma/rdma_netlink.h) contain only defines used by both > > kernel and application? In that case, the kernel may see unrecognized > > status value if it ever decides to check the status code when the > > response status is ERR. > > Get rid of the status value completely, it serves no current purpose. If in > future we need something we can always add a new attribute. > > Don't pollute the kernel headers with ibacm implementation details. OK. > > > > We need a way to encode three reply types, I suggest: > > > RDMA_NL_LS_F_ERR > > > For some reason the listener could not respond. The kernel should > > > issue the request on its own. Identical to a timeout. > > > Good flags, but an empty reply with no LS_NLA_TYPE_PATH_RECORDs > > > The listener responded and there are no paths. Return no paths > > > failure to requestor. > > > Good flags, and up to 6 LS_NLA_TYPE_PATH_RECORDs > > > Success > > > > Current implementation can be easily modified to handle these three cases. > > Are you going to use this scheme or do you have a different idea? Just use this scheme to avoid redundant queries to SA. Kaike > > > > There are only two remaining problems I see with the actual netlink > > > schema: > > > 1) There is no easy indication what port the request is coming > > > from. User space absolutely needs that to be able to forward a > > > request on to the proper SA. Yes, we could look at the SGID, but > > > with gid aliases that seems like alot of work for a performant > > > API. Ideas? Include the hardware port GUID? Port Number? Device > > > Name? > > > Not sure, but does need to be addressed. > > > > We can pass the device name and port number to the user application. > > The device and port_num are two of the parameters to > > ib_sa_path_rec_get(). > > That might be best, a ifindex would be even better, but we don't have one... > > 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
