On Wed, Jul 1, 2009 at 11:17 AM, Joachim Fenkes<fen...@de.ibm.com> wrote:
> Hal Rosenstock <hal.rosenst...@gmail.com> wrote on 01.07.2009 15:59:41:
>
>> > +static int redirect_port(ib_portid_t *port, uint8_t *mad)
>> > +{
>> > + port->lid = mad_get_field(mad, 64, IB_CPI_REDIRECT_LID_F);
>> > + if (!port->lid) {
>> > + IBWARN("GID-based redirection is not supported");
>> > + return -1;
>> > + }
>>
>> Sorry for the confusion: determination of GID redirection should be
>> based on a comparison of the RedirectGID to 0. It's valid to supply
>> both a non zero RedirectGID and RedirectLID.
>
> Are you sure?
No; I'm not sure. See previous post to Jason.
> About the Redirection GID, the spec says "If redirection is not being
> performed, this shall be set to zero", so if redirection _is_ being
> performed, the GID may or may not be zero without any explicit
> implication.
Agreed but Jason doesn't appear to agree.
> For the LID, it says "If this value is zero, the redirect requires the
> requester to use the supplied RedirectGID to request further path
> resolution
> from subnet administration." To me, this explicitly states that a zero LID
> means that the GID must be used.
>
> If both LID and GID are non-zero, it is not specified whether the
> requester
> should use the LID or the GID, so I choose to always use the LID as long
> as it's non-zero, because that's what the code supports.
It does say that the LID might not be valid even though non-zero. I'm
thinking of the more general case (future) rather than just IBM eHCA
usage.
> Am I talking crazy or does this make sense to you?
>> > +
>> > + port->qp = mad_get_field(mad, 64, IB_CPI_REDIRECT_QP_F);
>> > + port->qkey = mad_get_field(mad, 64, IB_CPI_REDIRECT_QKEY_F);
>> > + port->sl = mad_get_field(mad, 64, IB_CPI_REDIRECT_SL_F);
>> > +
>> > + /* TODO: Reverse map redirection P_Key to P_Key index */
>> > +
>> > + if (ibdebug)
>> > + IBWARN("redirected to lid 0x%x, qp 0x%x, qkey 0x%x, sl
> 0x%x",
>> > + port->lid, port->qp, port->qkey, port->sl);
>>
>> Unicast LIDs should be displayed in decimal rather than hex.
>
> Couldn't you have noticed this in the first patch? ;)
Somehow I missed it :-( Sorry.
>I'll change it.
Thanks.
-- Hal
> Cheers,
> Joachim
>
_______________________________________________
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
