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.
As described above this patch enables QP creation which is associated to
some underlay QP as of IPoIB QP. It comes to allow in downstream patches
a user space applications to accelerate send and receive traffic which
is typically handled by IPoIB ULP.
A successful QP creation will end-up by having an overlay QP (e.g. the
created one) which is associated to an already existing underlay one
(e.g. IPoIB QP).
The underlay QP is responsible for the transport, the packets on the
wire will hold its QPN, its pkey will be used, etc.
The overlay QP can steer incoming packets which were target to the
underlay QP into its own RQ. It can post send WQEs on its own SQ, the
hardware will use the transport properties of the underlay QP
to format the packets on the wire.
Note: The underlay QP should be in an RTR/RTS state in order to enable
the overlay QP to work properly.
Each QP should manage its properties and objects via modify, query and
destroy. Specifically, overlay QP can't affect the underlay QP
properties and vice versa.
--
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
