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:[EMAIL PROTECTED] > Sent: Mon 1/10/2005 11:22 PM > To: shaharf > Cc: Michael S. Tsirkin; Roland Dreier; [email protected] > 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 > > > > > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
