Hi Karl,
The idea in that if the received event is >= OSM_EVENT_ID_MAX,
then the plug-in knows that something went wrong (wrong version,
something changed in API, etc).
Also, you might want to know about more stuff if you're pulling
topology/routing info from SM, such as when SM became stand-by
and when it became master, and when re-route was done.
Please see this patch for reference:
http://www.mail-archive.com/[email protected]/msg02206.html
It wasn't applied as is back then, but you might want it now.
-- YK
On 13-Oct-11 4:50 AM, Karl Schulz wrote:
Thanks Ira,
My apologies for not following the conventional standard. Should I generate a
new patch?
-k
On Oct 12, 2011, at 5:13 PM, Ira Weiny wrote:
I think this is a reasonable idea.
Comment on the patch.
- OSM_EVENT_ID_MAX
+ OSM_EVENT_ID_MAX,
+ OSM_EVENT_ID_LIGHT_SWEEP_START,
+ OSM_EVENT_ID_LIGHT_SWEEP_DONE,
Traditionally the "MAX" value in the enum is kept at the end.
Ira
On Wed, 12 Oct 2011 14:31:07 -0700
Karl Schulz<[email protected]> wrote:
Hello,
Would it be possible to consider exposing light-sweep events to the current
OpenSM plugin interface? Something along the lines of the attached patch is
what we are using locally against opensm-3.3.9.
The motivation is to support a plugin module we have written to expose topology
information to a query service which can be used by MPI stacks (in user-space)
for topology-aware optimization and for topology-aware scheduling via batch
systems.
Thanks for the consideration,
Karl
--
Ira Weiny
Member of Technical Staff
Lawrence Livermore National Lab
925-423-8008
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
