Re: [OMPI devel] IB/OpenFabrics pow wow
Jeff Squyres wrote: Friday -- right, duh. My bad. So with everyone's replies so far, I think we're down to: 2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel 3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel 4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel If we get no more requirements, I'll arbitrarily pick one of these times. For me only #2 will work. On 29 I will be OOO all the day.
Re: [OMPI devel] IB/OpenFabrics pow wow
We seem to have 2 possible times: - #2: only OCG can't make it - #3/#4: only Pasha/Mellanox can't make it To be blunt, I'm inclined to go with #2 because it's more important for this conversation to have the already-existing players involved (because they're familiar with the code base). OCG: is there any chance you guys can make #2 work? On Nov 20, 2007, at 5:58 AM, Pavel Shamis (Pasha) wrote: Jeff Squyres wrote: Friday -- right, duh. My bad. So with everyone's replies so far, I think we're down to: 2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel 3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel 4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel If we get no more requirements, I'll arbitrarily pick one of these times. For me only #2 will work. On 29 I will be OOO all the day. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
Re: [OMPI devel] IB/OpenFabrics pow wow
Jeff Squyres wrote: We seem to have 2 possible times: - #2: only OCG can't make it - #3/#4: only Pasha/Mellanox can't make it To be blunt, I'm inclined to go with #2 because it's more important for this conversation to have the already-existing players involved (because they're familiar with the code base). OCG: is there any chance you guys can make #2 work? Well, I can attend, but Jon will be out of town... On Nov 20, 2007, at 5:58 AM, Pavel Shamis (Pasha) wrote: Jeff Squyres wrote: Friday -- right, duh. My bad. So with everyone's replies so far, I think we're down to: 2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel 3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel 4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel If we get no more requirements, I'll arbitrarily pick one of these times. For me only #2 will work. On 29 I will be OOO all the day. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] IB/OpenFabrics pow wow
Ok, let's go with #2. Thanks Steve. Specific call-in info coming shortly (not on the public list; no need for teleconference numbers to be spammed ;-) ). On Nov 20, 2007, at 10:25 AM, Steve Wise wrote: Jeff Squyres wrote: We seem to have 2 possible times: - #2: only OCG can't make it - #3/#4: only Pasha/Mellanox can't make it To be blunt, I'm inclined to go with #2 because it's more important for this conversation to have the already-existing players involved (because they're familiar with the code base). OCG: is there any chance you guys can make #2 work? Well, I can attend, but Jon will be out of town... On Nov 20, 2007, at 5:58 AM, Pavel Shamis (Pasha) wrote: Jeff Squyres wrote: Friday -- right, duh. My bad. So with everyone's replies so far, I think we're down to: 2. Mon, 26 Nov, 11am US East, 8am US Pacific, 6pm Israel 3. Thu, 29 Nov, 10am US East, 7am US Pacific, 5pm Israel 4. Thu, 29 Nov, 11am US East, 8am US Pacific, 6pm Israel If we get no more requirements, I'll arbitrarily pick one of these times. For me only #2 will work. On 29 I will be OOO all the day. ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres Cisco Systems
[OMPI devel] VT integration
I merged the current SVN trunk down to the vt-integration branch this morning (e.g., without the recent changes for OS X Leopard on the trunk, I couldn't build on my Mac laptop). However, because SVN merges take so long (this one took 1.5 hours), it ate up all my time before I have to leave for the US holiday. :-( I did a quick build and it looks like it built and installed ok, but I want to look a little deeper at the integration to make sure we're all on the same sheet of music. I hope to get to this Very Soon (because I've been the bottleneck in this process). -- Jeff Squyres Cisco Systems
Re: [OMPI devel] [OMPI svn] svn:open-mpi r16723
Sorry, saw this thread late. We'll try to make the change later today after a few meetings! brad On Nov 14, 2007 8:16 AM, Jeff Squyres (jsquyres) wrote: > > > > Tim - excellent catch! > > I totally agree. We must be very mindful of IP-related issues. > > -jms > Sent from my PDA > > > -Original Message- > From: Tim Prins [mailto:tpr...@cs.indiana.edu] > Sent: Wednesday, November 14, 2007 09:44 AM Eastern Standard Time > To: de...@open-mpi.org > Subject:Re: [OMPI devel] [OMPI svn] svn:open-mpi r16723 > > Hi, > > The following files bother me about this commit: > trunk/ompi/mca/btl/sctp/sctp_writev.c > trunk/ompi/mca/btl/sctp/sctp_writev.h > > They bother me for 2 reasons: > 1. Their naming does not follow the prefix rule > 2. They are LGPL licensed. While I personally like the LGPL, I do not > believe it is compatible with the BSD license that OMPI is distributed > under. I think (though I could be wrong) that these files need to be > removed from the repository and the functionality implemented in some > other way. > > > Tim > > > pen...@osl.iu.edu wrote: > > Author: penoff > > Date: 2007-11-13 18:39:16 EST (Tue, 13 Nov 2007) > > New Revision: 16723 > > URL: https://svn.open-mpi.org/trac/ompi/changeset/16723 > > > > Log: > > initial SCTP BTL commit > > Added: > >trunk/ompi/mca/btl/sctp/ > >trunk/ompi/mca/btl/sctp/.ompi_ignore > >trunk/ompi/mca/btl/sctp/.ompi_unignore > >trunk/ompi/mca/btl/sctp/Makefile.am > >trunk/ompi/mca/btl/sctp/btl_sctp.c > >trunk/ompi/mca/btl/sctp/btl_sctp.h > >trunk/ompi/mca/btl/sctp/btl_sctp_addr.h > >trunk/ompi/mca/btl/sctp/btl_sctp_component.c > >trunk/ompi/mca/btl/sctp/btl_sctp_component.h > >trunk/ompi/mca/btl/sctp/btl_sctp_endpoint.c > >trunk/ompi/mca/btl/sctp/btl_sctp_endpoint.h > >trunk/ompi/mca/btl/sctp/btl_sctp_frag.c > >trunk/ompi/mca/btl/sctp/btl_sctp_frag.h > >trunk/ompi/mca/btl/sctp/btl_sctp_hdr.h > >trunk/ompi/mca/btl/sctp/btl_sctp_proc.c > >trunk/ompi/mca/btl/sctp/btl_sctp_proc.h > >trunk/ompi/mca/btl/sctp/btl_sctp_recv_handler.c > >trunk/ompi/mca/btl/sctp/btl_sctp_recv_handler.h > >trunk/ompi/mca/btl/sctp/btl_sctp_utils.c > >trunk/ompi/mca/btl/sctp/btl_sctp_utils.h > >trunk/ompi/mca/btl/sctp/configure.m4 > >trunk/ompi/mca/btl/sctp/configure.params > >trunk/ompi/mca/btl/sctp/sctp_writev.c > >trunk/ompi/mca/btl/sctp/sctp_writev.h > > > > > > Diff not shown due to size (201438 bytes). > > To see the diff, run the following command: > > > > svn diff -r 16722:16723 --no-diff-deleted > > > > ___ > > svn mailing list > > s...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/svn > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel >
Re: [OMPI devel] initial SCTP BTL commit comments?
On Nov 19, 2007 4:49 PM, Jeff Squyres wrote: > Are there API functions or data structures that can be used to > determine if the 1-to-many model is supported on the system? I don't see how this will be possible because the 1-to-many model is supported in some way on all systems... I'll try to explain more clearly below... > More specifically: can you have your configure.m4 script check to see > if the current system a) supports SCTP, Yes, the current configure.m4 does this by making use of OMPI_CHECK_PACKAGE. > and b) if yes, if it supports 1-to-many? This kind of checking would > theoretically > allow running on Solaris This is a little more tricky. (Once again, I'm speaking as how things were with SCTP in Solaris based on a Nov 2006 email, so someone please correct me if I'm wrong!) Solaris has 1-to-many support... just it makes different assumptions. In general on all platforms support SCTP, with a one-to-many socket, you can implicitly establish an "association" (what SCTP calls a multihomed connection) by just calling sctp_sendmsg and passing the appropriate sockaddr; no explicit connect() is required. Use of sctp_sendmsg is supported on a Solaris one-to-many socket for *only* the initial association establishment; after this first call, one must query the socket to find out the assigned "association ID" to that association and then use that as a parameter to another function called sctp_send in order to send data. At least, this is how it was explained to me; I've never played with this myself yet and am not sure if this approach would work on other platforms. How would an autoconf rule go that far into determining the underlying stack's assumed one-to-many semantics? >, but automatically default to the 1-to-1 mode (if your BTL supports that). Hmm, I suppose you're right. We could just make Solaris set the MCA variable btl_sctp_if_11 to 1 in order to use the 1-to-1 mode to avoid this mess. How would one change the default of an MCA variable in an autoconf rule? I really hope there's a way to keep one-to-many the default as often as possible (if not always). You can tell that I am not as good at autoconf as the rest of you are! Bearing that in mind, I actually had another question of my own... The SCTP API is typically within it's own library called libsctp. However, in FreeBSD 7, the API is within libc. So say we're looking for something like sctp_recvmsg (as we do now)... what is the best way to structure an autoconf rule to look for this in either libsctp or libc, and to not complain if libsctp doesn't exist? Should I just call OMPI_CHECK_PACKAGE once with libsctp and if that fails then call OMPI_CHECK_PACKAGE again with libc? > This also falls in-line with the autoconf mantra: test for the desired > behavior, not the desired platform (because the list of supported > platforms may change over time). :-) Good point. At the moment, yes the configure.m4 just looks for particular platforms namely those that I've had the time to try. Hopefully in the future instead of specifying those that work, I can instead specify those that don't, but for now with such a young stack, it might make more sense to be pessimistic and assume that a given platform will not work. It will make maintaining the BTL easier as well ;-) Just my $.02... brad > > > On Nov 14, 2007, at 1:17 PM, Brad Penoff wrote: > > > On Nov 14, 2007 5:11 AM, Terry Dontje wrote: > >> > >> Brad Penoff wrote: > >>> On Nov 12, 2007 3:26 AM, Jeff Squyres wrote: > >>> > I have no objections to bringing this into the trunk, but I agree > that > an .ompi_ignore is probably a good idea at first. > > >>> > >>> I'll try to cook up a commit soon then! > >>> > >>> > One question that I'd like to have answered is how OMPI decides > whether to use the SCTP BTL or not. If there are SCTP stacks > available by default in Linux and OS X -- but their performance > may be > sub-optimal and/or buggy, we may want to have the SCTP BTL only > activated if the user explicitly asks for it. Open MPI is very > concerned with "out of the box" behavior -- we need to ensure that > "mpirun a.out" will "just work" on all of our supported platforms. > > >>> > >>> Just to make a few things explicit... > >>> > >>> Things would only work out of the box on FreeBSD, and there the > >>> stack > >>> is very good. > >>> > >>> We have less experience with the Linux stack but hope the > >>> availability > >>> of and SCTP BTL will help encourage its use by us and others. Now > >>> it > >>> is a module by default (loaded with "modprobe sctp") but the actual > >>> SCTP sockets extension API needs to be downloaded and installed > >>> separately. The so-called lksctp-tools can be obtained here: > >>> http://sourceforge.net/project/showfiles.php?group_id=26529 > >>> > >>> The OS X stack does not come by default but instead is a kernel > >>> extension: > >>> http://sctp.fh-muenster.de/sctp-nke.h
[OMPI devel] OMPI Bug Status
At today's OMPI concall meeting it was decided some bug management was appropriate. In order to do this we would like the community to do the following two tasks: 1. Review all 1.2.X bugs under trac send email to the devel alias as to the bugs you think should be fixed for 1.2.5 and beyond. Any of the bugs not included on these list will be considered as items that can be either dropped or pushed to 1.3 and beyond. 2. Update all bugs under the 1.3 and Future milestones with pertinent information. We would like these tasks done before the Dec 4th concall so we can discuss where we are at with our current set of bugs. thanks, Terry and Rich
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r16762
George -- I assume that this needs to go to 1.2.5 as well, right? Can you file a CMR? On Nov 20, 2007, at 10:10 PM, bosi...@osl.iu.edu wrote: Author: bosilca Date: 2007-11-20 22:10:05 EST (Tue, 20 Nov 2007) New Revision: 16762 URL: https://svn.open-mpi.org/trac/ompi/changeset/16762 Log: After the 10.5.1 update this bug is still valid. Remove the -g from all Leopard versions (until they fix it). Text files modified: trunk/config/ompi_config_asm.m4 | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Modified: trunk/config/ompi_config_asm.m4 = = = = = = = = == --- trunk/config/ompi_config_asm.m4 (original) +++ trunk/config/ompi_config_asm.m4 2007-11-20 22:10:05 EST (Tue, 20 Nov 2007) @@ -809,7 +809,7 @@ OMPI_VAR_SCOPE_PUSH([ompi_config_asm_flags_new ompi_config_asm_flag]) AC_MSG_CHECKING([if need to remove -g from CCASFLAGS]) case "$host" in -*-apple-darwin9.0*) +*-apple-darwin9.*) for ompi_config_asm_flag in $CCASFLAGS; do if test "$ompi_config_asm_flag" != "-g"; then ompi_config_asm_flags_new="$ompi_config_asm_flags_new $ompi_config_asm_flag" ___ svn-full mailing list svn-f...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/svn-full -- Jeff Squyres Cisco Systems
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r16762
https://svn.open-mpi.org/trac/ompi/ticket/1187 is the CMR related to this bug. george. On Nov 20, 2007, at 8:11 PM, Jeff Squyres wrote: George -- I assume that this needs to go to 1.2.5 as well, right? Can you file a CMR? On Nov 20, 2007, at 10:10 PM, bosi...@osl.iu.edu wrote: Author: bosilca Date: 2007-11-20 22:10:05 EST (Tue, 20 Nov 2007) New Revision: 16762 URL: https://svn.open-mpi.org/trac/ompi/changeset/16762 Log: After the 10.5.1 update this bug is still valid. Remove the -g from all Leopard versions (until they fix it). Text files modified: trunk/config/ompi_config_asm.m4 | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Modified: trunk/config/ompi_config_asm.m4 = = = = = = = = = = --- trunk/config/ompi_config_asm.m4 (original) +++ trunk/config/ompi_config_asm.m4 2007-11-20 22:10:05 EST (Tue, 20 Nov 2007) @@ -809,7 +809,7 @@ OMPI_VAR_SCOPE_PUSH([ompi_config_asm_flags_new ompi_config_asm_flag]) AC_MSG_CHECKING([if need to remove -g from CCASFLAGS]) case "$host" in -*-apple-darwin9.0*) +*-apple-darwin9.*) for ompi_config_asm_flag in $CCASFLAGS; do if test "$ompi_config_asm_flag" != "-g"; then ompi_config_asm_flags_new="$ompi_config_asm_flags_new $ompi_config_asm_flag" ___ svn-full mailing list svn-f...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/svn-full -- Jeff Squyres Cisco Systems ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel smime.p7s Description: S/MIME cryptographic signature
