Rimmer, Todd wrote: > My recommendation is option 2. Thanks for the response.
> In large fabrics the SA can be a bottleneck. It is best for an end node > to register with the SA only for the events which are of actual interest > to the end node. Which part of the SA is the bottleneck? Is it the sending of MADs, or the processing of events to determine which end nodes are interested in the event? My thinking was that if events are rare, then having the SA simply forward the events to the end nodes saves processing time on the SA. So, we can trade off SA processing by sending more MADs. I'm not sure which is worse. > With regards to "duplicating dispatching code on every node", rather > than duplication, think of this as "distributing event dispatching code > among the interested nodes". Thinking of it in these terms makes option > 2 stand out as more scalable. To provide the highest level of filtering at the SA, we need an interface based on Informinfo. Trying to reference count at that level would be difficult. (E.g. client 1 wants events for LIDs 2-25, client 2 LIDs 3-4, client 3 LIDs 2-25, client 4 LIDS 15-30, etc.) I'm not sure we need an interface this complex. It increases the processing requirements needed of the SA, and may increase the number of MADs that it needs to send to a given node. (Unless we start trying to be really clever with the registration.) I was thinking of letting clients register for a particular "class" of event, then dispatching the events among the registered clients. But I'm still uncertain about how to define event classes. Some expected usage models would be helpful. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
