[openib-general] Re: ib_mad.h ib_mad_agent.hi_tid
Sean Hefty
mshefty at ichips.intel.com
Wed Sep 1 11:15:35 PDT 2004
On Wed, 01 Sep 2004 14:57:03 -0400
Hal Rosenstock <halr at voltaire.com> wrote:
> As long as the CM clients use the hi_tid assigned by the access layer in
> forming their TIDs, I don't see a problem with multiple active CMs.
The problem is routing MADs back to the proper CM without the access layer knowing the CM protocol. E.g. when a REP is received by the access layer, it can route the REP to the client registered to receive CM MADs based on the management class, or it needs to look at the management class, see that it's the CM, check the method, and then route based on the TID to the proper client. And getting the DREQ to the right CM would be difficult, so requires the CM to be active for all message sequences (REQ, DREQ, and LAP).
I'm slowly remembering why we treated CM MADs differently and routed them to the one and only CM in all cases.
> > My preference is for the access layer to know as little about the CM protocol
> > as possible.
>
> Mine as well.
I only wish that the architects had shared this view...
> I'm back to where I was on this as adding a flag seems of minimal
> benefit as you point out. So I would have the access layer set
> unsolicited TIDs with the exception of Send methods (CM and other
> clients using the Send method need to handle their own TIDs on send).
> If that is deemed too unclean, then all send TID handling is back at
> the client :-(
At this point, my vote is for the clients to set the TID in all cases, but are required to use the upper TID assigned to them by the access layer. Clients already need to manage and set the lower TID, so this isn't a big issue.
> Also, should the access layer validate that the client uses the hi_tid
> supplied in the mad_agent in the TIDs of sent MADs ?
It's probably not worth it. Since response TIDs have to match requests, adding this checks puts us back to having the access layer determine if a MAD is unsolicited before the check is done, which brings back all of the CM issues...
More information about the general
mailing list