On Thu, Sep 07, 2017 at 09:46:39PM +0300, Alex Rosenbaum wrote: > On Thu, Sep 7, 2017 at 6:16 PM, Jason Gunthorpe > <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Sep 07, 2017 at 03:12:05PM +0300, Yishai Hadas wrote: > >> +uint32_t source_qpn; /* Source QP number, creation flag IBV_QP_CREATE_SOURCE_QPN should be set */ > > > > I think more discussion in the man page is required for this > > feature. Eg that it is a SEND ONLY QP and only works for UD. > > Verbs UD QP can handle receive of ingress packets sent with > BTH.DestQPN = ibv_qp->qp_num. This is applicable also in this case. > > Also, future implementation might include RC source qpn use case. This > can be accomplished by setting the HCA's QPN to be the same as the > 'source qpn' value, and returning that to the user. > > We prefer not to limit the API definition in the man page. Well, you have to define what the API does, specifically. If you expect it to RX then you need to specify that. Does it steal the traffic? Does it get a copy? Do you need to use flow steering to do that? Same for RC. There is nothing wrong with specifying the API limit that exist today, it helps people understand what the feature is and how to use it. 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