[openib-general] Re: ib_mad.h ib_mad_agent.hi_tid

[Sean Hefty]

On Wed, 01 Sep 2004 13:34:11 -0400
Hal Rosenstock <halr at voltaire.com> wrote:

> The one additional complication appears to be when a REJ is sent by the
> active side from the Timeout or REP Wait state as a result of CM
> protocol timeout. The CM protocol timeout is indicated by Message
> REJected = 2. Reason code is 4 for timeout. Does the access layer need
> to make exceptions for those REJs ?

...gurgle...

Here's what we did for the SF stack.  All CM MADs were routed at the receive side using a dispatch table based on "unsolicited" registration.  (There was a special check for the CM class.)

The impact was that a client other than the CM could not initiate a connection request by sending a REQ directly.  It would be nice to avoid this restriction, which should allow multiple "active" side CMs to co-exist, but definitely isn't a requirement, and probably involves embedding a good deal of the CM protocol into the access layer.  On the send side, the access layer did not change the TID for CM MADs.

My preference is for the access layer to know as little about the CM protocol as possible.  I think it would be nice if the access layer could examine something as simple as the R bit to determine if it needed to set the upper TID, but that's not possible given the CM protocol.  As an alternative, we could extend the mad_flags to indicate if sent a MAD should be treated as: default (no flag set, so check the R bit), solicited (do not set TID), or unsolicited. (set TID).

Of course, if the client needs to set a flag, it could just set the TID directly and be done...  Maybe this is the way to go on the send side.

What are your thoughts on this?