> > On Tue, May 19, 2015 at 02:27:22PM -0600, Hefty, Sean wrote: > > > I have mixed feelings about using the SA message format for this. > > > > > > In-kernel we don't use that format, and many of the newer APIs were > > > designed around passing the GMP,Forward,Return path tuple, not just > > > a naked GMP. > > > > I think the choice of the netlink protocol is a largely matter of > > taste. In the internal review of these patches, the netlink hook was > > previously in the mad layer, which would have allowed redirecting any > > mad to user space. (The code only attempted to redirect SA queries.) > > Trying to hook from within ib_mad added a fair amount of complexity, > > that moving up into sa_query avoided. The proposed interface would > > allow moving the changes back down, versus limiting this only to the > > SA query calls. (And I'm not meaning to imply that limiting this only > > to SA queries is a bad choice.) > > > > > I'd rather see the netlink data ask for what the kernel needs (eg UD > > > path to X, RC path to X) and return the new format we've already > > > established for AF_IB > > > > Does anyone else have input on the netlink protocol? Hal/Ira? MADs seem > more flexible, but higher-level structures more efficient and natural. > > > The idea was to implement a local SA cache. Nothing more. A lot of what is > being discussed is beyond the intent of the patches. > > Ira The higher-level scheme discussed so far can be implemented using similar mechanism (netlink), but with a different netlink multicast group, and therefore different data exchange format. Maybe it should be done in another patch series. Kaike -- 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
