[ofa-general] Re: [ewg] [PATCH 3/9] ib_core: RDMAoE support only QP1
Hal Rosenstock
hal.rosenstock at gmail.com
Wed Jun 17 04:14:56 PDT 2009
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;
>
>
More information about the general
mailing list