[openib-general] Some Missing Features from mthca/user MADaccess

[Hal Rosenstock]

On Tue, 2005-01-11 at 04:43, shaharf wrote:
> But maybe we should add a flag(s) to this agent registration to
> set/clear the is_SM bit? you can check that you are granted "respond"
> permission on qp0 before allowing it.

Not sure what you mean exactly by "respond" permission on QP0. Multiple
clients can respond on QP0 with the existing API.

How does OpenSM register for SMI ? What do the registrations look like ?
I'm not sure we want to lock in is_sm setting and clearing on these
anyhow rather than the mechanism previously proposed (special file).
 
> BTW, what the reasoning behind having a method mask? What is the
> point? Is it due to historical reasons?

The point was to allow different applications to get different methods.
There was debate about going down to the attribute level but that need
was not deemed as necessary. 

> Note that filtering methods that can be handled by an application is
> problematic. 

Can you elaborate on what the issue(s) is/are ? Is it what you write
below or something else ? 

There is also the transaction based paradigm as well to handle other
cases.

> MHO is that the correct thing to do is to let the application reply an
> error. Failing to do that may cause applications to conclude that the
> responding application is dead.

I don't think there is anything preventing a response. So I'm likely not
following what you mean here.
 
> On the other hand, attributes mask are much more reasonable. It may
> allow you to split qp0/qp1 responsibilities to several applications on
> the same node. This may be applicable to SA attributes. For example, I
> am not sure why the OpenSM have to manage the service record database.
> Such attributes mask will enable us to distribute it.

I think it still can be distributed. The threads either need to share a
registration (mad_agent) if they are using filtering (methods) or they
can have their own registration if they use TID based request/response.
BTW, TID based request/response is what was envisioned for managers (and
allows for a better distribution model in that they don't need to rely
on a shared mad_agent).

Filtering on attribute could be done and was argued for back when the
API was being discussed but the consensus was that we could live without
it. With attribute filtering, I think you could direct a specific
attribute to a specific thread easier.

> In the current state only the SM should request to respond on any
> methods, unless you can be certain that no SM is required to run on
> the same port.

The SM might use TID based approach rather than method based filtering
for its outoing request/incoming response work. SA is more incoming
request/outgoing response and so that would be method (filtering) based.

Can you provide any examples where the TID based approach is
insufficient ? I think you have touched on one example: Since the SA
uses method filtering, if the SA were to be multithreaded with different
threads handling different attributes, this demux could be pushed down
to the MAD layer. An alternative is to demux this at a low layer in
OpenSM to dispatch the attribute to the proper thread. I'm not sure
there is a compelling reason to push this into the MAD layer but I'm
open to hearing and learning more.

-- Hal

>  
> Shahar
> 
> 
> ______________________________________________________________________
> From: Hal Rosenstock [mailto:halr at voltaire.com]
> Sent: Mon 1/10/2005 11:22 PM
> To: shaharf
> Cc: Michael S. Tsirkin; Roland Dreier; openib-general at openib.org
> Subject: RE: [openib-general] Some Missing Features from mthca/user
> MADaccess
> 
> 
> 
> On Mon, 2005-01-10 at 11:30, shaharf wrote:
> > Thinking about it, I think there is another alternative which maybe
> > cleaner: automatically raise the issm bit if someone registers to
> answer
> > sminfo attr.
> 
> There is no such registration currently so this approach is moot.
> 
> -- Hal
> 
> 
> 
> 
> 
>