[openib-general] GSI compromise

[Sean Hefty]

On Tue, 03 Aug 2004 21:19:39 -0700
Roland Dreier <roland at topspin.com> wrote:

> This looks pretty sane to me -- I really like the proposed way of
> handling redirection.

Thanks for reviewing this.

>  - what callback will a consumer receive if no response is received
>    before a send timeout?

Hmm... maybe some sort of transaction status needs to be added to the ib_mad_msg to indicate a timeout on the send.  I'm not sure we want to override the work completion status for this...

>  - where does transaction ID allocation happen?

I was assuming with the registration call.  The client TID should probably be placed inside struct ib_mad_reg.

>  - how does the MAD layer know how many elements are in the
>    method_array parameter of ib_mad_reg_class()?

I was assuming a fixed size of 127 elements.  (At least I think it's 127 methods per class.)  This could probably be an optional argument if the registration is for all methods of a given class.

>  - where is the GRH info stored if ib_mad_msg.global_route is set?

buf would point to the start of the MAD, including the GRH.  Based on a separate mail, I'm still trying to figure out the best way to send/receive MADs without unnecessary data copies.

>  - should we use a "struct list_head" instead of our own type for
>    ib_mad_msg.next?

I'm fine with this.  I followed what I had for the work requests.  Maybe those should change as well?

>  - I assume we'll have helpers for parsing ClassPortInfo redirection
>    responses and updating a message.

I'm good with redirection helper routines.  I'd just like to get a clean layering.  Btw, does anyone know if you can redirect in the midding of sending an RMPP message?

>  - are any values other than IB_QPT_SMI and IB_QPT_GSI valid for the
>    qp_type parameter of ib_mad_reg_class()?

I wasn't thinking that there would be.  In fact, I was considering the impact of removing ib_get_spl_qp from the exposed access layer API.  I was also considering preventing calls to ib_modify_qp/ib_destroy_qp from using a QP of type SMI/GSI, but allowing calls to ib_query_qp to pass through.  Thoughts?

>  - should ib_qp_redir()/ib_process_wc() have "_mad_" in their name to
>    give more of a clue as to what they do?

Probably. :)

>  - are you thinking that a single "support RMPP" flag would be passed
>    into ib_mad_reg_class() and ib_qp_redir()?

That is my current thought.  If the flag is set, it indicates that the class/methods being accessed by the user carry the RMPP header.  I think that this would allow a vendor to define their own MADs, but take advantage of RMPP as long as the standard RMPP header was used.