> > > +/* 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.
> > 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?
> > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
