> > > From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] > > Sent: Thursday, June 11, 2015 8:22 PM > > To: Wan, Kaike > > Cc: linux-rdma@xxxxxxxxxxxxxxx; Fleck, John; Weiny, Ira > > Subject: Re: [PATCH v5 1/4] IB/netlink: Add defines for local service > > requests through netlink > > > > On Thu, Jun 11, 2015 at 11:45:46PM +0000, Wan, Kaike wrote: > > > Apparently, to achieve this goal, we need the following changes: > > > > I don't expect anything more than a proper hole in the UAPI to make > > this work. > > > > I already have patches that implement full kernel support for the > > 6-path format, and globally enable APM. With this netlink interface it > > becomes feasible to mainline them. That will require some reworking of > > what you've done, but I don't expect you to do that. > > > > The only remaining thing we need here is that tiny bit of policy > > information for the kernel to specify what the intended use of the path is: > > - For connected CM operation (6 path records) > > - For unidirectional UD (1 path record) > > - For 'misc' GMP like operation (at least 1 reversible path record) > > > > I'm happy if you call it PATH_USE_XX > > > > Testing the reversible bit should be enough to rough this in, if not > > reversible it is PATH_USE_UNIDIRECTIONAL_UD, otherwise it is > PATH_USE_GMP. > > PATH_USE_* is a better name. But I think the defines should be: PATH_USE_ANY (or ALL?) PATH_USE_UNIDIRECTIONAL PATH_USE_GMP > > Recommend that userspace treat any unknown usage type as GMP (it is > > the > > > most general). Why not treat unknown type as "ANY/ALL" and return all 6 if possible. If not possible/supported (ie like ibacm) return GMP which is always valid. > > That would be cool. If we add this attribute, should we remove reversible and > numb_path attributes? Yes. > > Kaike > > > > > Ira: Do you like 'path use' better as a name? I think I do.. Yea that is a much better name. Thanks, Ira -- 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
