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

[Hal Rosenstock]

On Wed, 2004-09-01 at 14:15, Sean Hefty wrote:
> 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.  

I was thinking the latter.

> 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).

Yup, that's the crux of this. The passive CM is not always so passive
:-(

> I'm slowly remembering why we treated CM MADs differently and routed them 
> to the one and only CM in all cases.

Me too. CM is a hairball. 

I think it is acceptable to run a single CM at any one time. This
doesn't preclude running different CM implementations if more than one
is interesting to OpenIB; just not at the same time. If anyone thinks
otherwise, now is the time to speak your piece.

> > > 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...

It would be nice to rewrite history on this...

> > 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.

OK.

> > 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...

Right.

-- Hal