On Thu, Jun 01, 2017 at 05:42:25PM +0300, Yishai Hadas wrote: > On 5/30/2017 7:04 PM, Jason Gunthorpe wrote: > >On Tue, May 30, 2017 at 10:15:57AM +0300, Leon Romanovsky wrote: > >>From: Yishai Hadas <yishaih@xxxxxxxxxxxx> > >> > >>Enable QP creation which is associated to underlay QP. > >>The created QP will manage the scattering objects as of RQ and SQ, while > >>the transport attributes will be managed by its underlay QP > >> > >>This comes as a pre-patch for downstream patches in this series to > >>enable flow steering on the underlay IPoIB QP. > > > >I think you need to define the semantics here much more precisely. > > Sure, please find below some clarifications on the semantics and the usage, > will add as part of V1 to this commit log. I feel like this is really convoluted.. Sounds like the goal here is to allow user space to setup a send-only 'QP' with a fixed QPN, and a receive-only 'QP' associated with the existing flow rule stuff Why not do this directly? Why do we need this semanticly odd association with an 'underlay QP' ? What happens if thi underlay qp is deleted? Or reconfigured? How does security work? This is all root-only, right? 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
