On Tue, May 19, 2015 at 03:20:09PM -0600, Hefty, Sean wrote: > > I'm not sure there is much use case for letting user space get > > involved in arbitary MAD traffic.. > > I was thinking more about easily supporting other queries - ServiceRecords, MCMemberRecords, etc. The only use case I'm currently aware of is PathRecords, however. > I think MCMemberRecords (including joins) are good future candidates for this interface. The SSA work which Hal is doing had some plans for doing this. > > Over generalizing feels like over design and doesn't let us add > > valuable information that could help push policy decisions into user > > space, like passing the IP and TOS, QP type, etc when available, to > > userspace. > > I agree. This level of control would be better. The current security model of IB seems hopelessly broken. IMO, all path data should come from privileged users, without any ability of the app to modify it. > I agree with your statement but I'm not sure how Jasons proposal helps to control the use of PR data. As long as verbs supports the individual setting of PR data such as SL an application can change this data. > Changing the protocol shouldn't be a big deal, though if you wanted to make my life easy, we could just adopt the ibacm sockets protocol directly. :) > ib_sa_path_rec_get is pretty specific in what it does. Without over designing, this series adds access to the existing SA data cache (ibacm) for those users who call this function. I think that extending this to return an array of paths should be tackled in future patches. This future work could use a different protocol but I don't think it would be part of ib_sa_path_rec_get. 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
