On Thu, Sep 7, 2017 at 10:29 PM, Jason Gunthorpe <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> wrote: > 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. Like any other QP, this too can have a max_recv_wr defined by user. I don't think we need to specifically mention it, because it is not a limition. > Does it steal > the traffic? Does it get a copy? Do you need to use flow steering to > do that? Yes, this QP can support flow steering based on IBV_DEVICE_MANAGED_FLOW_STEERING. > 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. RC is currently not supported. Do you prefer we update the man page with the UD limitation? and once RC or other limitation are removed we update it again? Alex -- 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
