Re: OpenSM plugin patch request
On Oct 17, 2011, at 5:28 PM, Hal Rosenstock wrote: > > A couple of minor comments: > > 1. Why not move the OSM_EVENT_ID_LIGHT_SWEEP_DONE event to where "LIGHT > SWEEP COMPLETE" is indicated in osm_state_mgr.c ? That's actually more > accurate as all the transactions have completed. > > 2. The new events should be added to osmeventplugin/src/osmeventplugin.c > example. > > Thanks. > > -- Hal > Thanks for the comments. The attached osm_light_sweep.patch addresses the points above by moving the OSM_EVENT_ID_LIGHT_SWEEP_DONE event to be with it's corresponding LIGHT SWEEP COMPLETE log message. Also, the light sweep START/DONE events are included in the example event plugin. While adding to the example event plugin, I realized that the autoconf setup in 3.3.9 does not appear to be propagating all user settings down into the default plugin. Consequently, I was not able to build the plugin when OFED headers were not in the default location. In case it's useful (and hasn't already been addressed), the second attached patch adds $(OSMV_INCLUDES) to the automake directives for the plugin which was sufficient in my case to resolve necessary headers. Thanks, Karl osm_light_sweep.patch Description: osm_light_sweep.patch build.patch Description: build.patch
Re: OpenSM plugin patch request
Hi Karl, On 10/17/2011 5:43 PM, Karl Schulz wrote: > Thanks for explaining the enum convention - quite logical indeed. Also, > thanks for some > of the off-list discussion where we tried to see if any of the current event > callbacks > could be used to achieve the desired support. As it stands, it still sounds > like including > light sweep events is the simplest solution and I'm attaching an updated > patch for consideration which honors the MAX convention. A couple of minor comments: 1. Why not move the OSM_EVENT_ID_LIGHT_SWEEP_DONE event to where "LIGHT SWEEP COMPLETE" is indicated in osm_state_mgr.c ? That's actually more accurate as all the transactions have completed. 2. The new events should be added to osmeventplugin/src/osmeventplugin.c example. Thanks. -- Hal > Thanks, > > Karl > > > On Oct 13, 2011, at 7:50 AM, Yevgeny Kliteynik wrote: > >> 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/linux-rdma@vger.kernel.org/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 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 wei...@llnl.gov >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in >>> the body of a message to majord...@vger.kernel.org >>> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OpenSM plugin patch request
Thanks for explaining the enum convention - quite logical indeed. Also, thanks for some of the off-list discussion where we tried to see if any of the current event callbacks could be used to achieve the desired support. As it stands, it still sounds like including light sweep events is the simplest solution and I'm attaching an updated patch for consideration which honors the MAX convention. Thanks, Karl On Oct 13, 2011, at 7:50 AM, Yevgeny Kliteynik wrote: > 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/linux-rdma@vger.kernel.org/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 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 >>> wei...@llnl.gov >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> opensm.patch Description: opensm.patch
Re: OpenSM plugin patch request
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/linux-rdma@vger.kernel.org/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 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 wei...@llnl.gov -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OpenSM plugin patch request
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 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 > wei...@llnl.gov -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OpenSM plugin patch request
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 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 wei...@llnl.gov -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OpenSM plugin patch request
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 opensm.patch Description: opensm.patch
