[ewg] [PATCH 3/9] ib_core: RDMAoE support only QP1

[Hal Rosenstock]

On Wed, Jun 17, 2009 at 7:10 AM, Eli Cohen<eli at dev.mellanox.co.il> wrote:
> On Mon, Jun 15, 2009 at 02:26:42PM -0400, Hal Rosenstock wrote:
>> Should ib_post_send_mad return some error on QP0 sends on RDMAoE ports ?
> You can't send anything over QP0 because it is not created and so
> there are no data structs corresponding to it.

Yes, I understand that's the intention but I didn't see where a MAD
posted to QP0 returns an error. Does that occur ? Or is it just
silently dropped ?

>> What QP1 sends are allowed ?
> Basically, all QP1 sends are allowed without any changes - QP1
> functions as normal.
> However, RDMAoE will initially support only the CM. In the future, we
> can support additional QP1 services.

So what happens with other QP1 sends now ? Do they go into hyperspace
and then timeout ?

>> Is it only SA sends which are faked ?
> Yes
>
>> How
>> are others handled ? These questions are important to what happens to
>> the IB management/diag tools when invoked on an RDMAoE port. We need
>> to be able to handle that scenario cleanly.
> You should be able to to send MADs over QP1 from the kernel. I did not
> make any tests as for sending MADs from userspace but I can't think of
> a reason why this would be a problem.

There are a set of tools (infiniband-diags and ibutils) which do send
MADs from userspace. I'm concerned that if someone tries these, the
right thing will happen.

-- Hal

>>
>> Is something similar needed in ib_mad_port_close for handling no QP0
>> on RDMAoE ports in terms of destroy_mad_qp/cleanup_recv_queue calls ?
>>
> No, becuase it is handled inside destroy_mad_qp():
>
>        if (!qp_info->qp)
>                return;
>
>