Re: [PATCH rdma-next 1/6] IB/core: Enable QP creation which is associated to underlay QP

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Tue, Jun 06, 2017 at 06:49:52PM +0300, Alex Rosenbaum wrote:
>    IPoIB is a tunneled protocol. The underlay part, a UD QP, has a set of
>    properties that define its L2-L4 characteristics. In this suggestion we
>    wanted to make sure the overlay will use the same QP so that there are
>    no mismatches between the IB layer properties. An example for such a
>    mistake can be if the overlay sets a PKey which is different than the
>    IPoIB UD QP. A mistake example on the receive flow; when setting
>    multiple ingress steering on using multiple different PKey's into a
>    single user space UD QP.

That seems like a strange thing to worry about, any user of this
already has to closely track all of the IB parameters as they are
required to issue path records.

So this underlay/overlay complexity really doesn't do much for
safety/usability, IMHO - it just introduces more complexity and more
failure modes.

>    Naming it "source_qpn" instead of associated, as you suggest, sound
>    more appropriate.

Simpler, certainly if you completely eliminate the notion of a linkage
to another QP. This is just creating a TX QP with a specified QPN that
can overlap an existing bidir QP's QPN.

This could then also be potentially used for applications that desire a
fixed QPN.

>    As noted in previous email, the overlay QP can work properly only when
>    the underlay QP is not in RTR or RTS. Meaning no egress or ingress
>    traffic will happen once underlay is not in these states. This is

Yuk, a hidden variable that causes undetectable failure is gross.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html