Re: [OMPI devel] SHMEM v1.7 merge proposal

2013-10-29 Thread Mike Dubman 
Hi,
This is exactly the way we handle it now. We have internal branch on top of
v1.7 with all SHMEM code in it.
It runs mtt and other tests.

Once we done with all changes - we will provide patch (and branch direct
access if needed) for GK.

Kind Regards
Mike.


On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W wrote:

> All -
>
> Ralph and I talked today about the logistics of bringing the OpenSHMEM
> code to the 1.7 release branch, as it's now a fairly large set of changes
> from the trunk.  What we propose is to follow the same proceedure we used
> when merging in the RTE framework change, which is essentially a staging
> branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> bring the OpenSHMEM changes into that (and hopefully test), and then file
> a single CMR for the changes from the branch.  If done properly, the GK
> then only has to merge with --reintegrate and we're set.
>
> Let's talk about it on the call tomorrow, but that's the current proposal.
>
> Brian
>
> --
>   Brian W. Barrett
>   Scalable System Software Group
>   Sandia National Laboratories
>
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

Re: [OMPI devel] SHMEM v1.7 merge proposal

2013-10-29 Thread Jeff Squyres (jsquyres) 
I think Brian's point is that it should be a SVN branch.


On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:

> Hi,
> This is exactly the way we handle it now. We have internal branch on top of 
> v1.7 with all SHMEM code in it.
> It runs mtt and other tests.
> 
> Once we done with all changes - we will provide patch (and branch direct 
> access if needed) for GK.
> 
> Kind Regards
> Mike.
> 
> 
> On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W  wrote:
> All -
> 
> Ralph and I talked today about the logistics of bringing the OpenSHMEM
> code to the 1.7 release branch, as it's now a fairly large set of changes
> from the trunk.  What we propose is to follow the same proceedure we used
> when merging in the RTE framework change, which is essentially a staging
> branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> bring the OpenSHMEM changes into that (and hopefully test), and then file
> a single CMR for the changes from the branch.  If done properly, the GK
> then only has to merge with --reintegrate and we're set.
> 
> Let's talk about it on the call tomorrow, but that's the current proposal.
> 
> Brian
> 
> --
>   Brian W. Barrett
>   Scalable System Software Group
>   Sandia National Laboratories
> 
> 
> 
> 
> ___
> 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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] SHMEM v1.7 merge proposal

2013-10-29 Thread Mike Dubman 
will it be ok, that once all is ready, we push git2svn branch for this?


On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:

> I think Brian's point is that it should be a SVN branch.
>
>
> On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:
>
> > Hi,
> > This is exactly the way we handle it now. We have internal branch on top
> of v1.7 with all SHMEM code in it.
> > It runs mtt and other tests.
> >
> > Once we done with all changes - we will provide patch (and branch direct
> access if needed) for GK.
> >
> > Kind Regards
> > Mike.
> >
> >
> > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W 
> wrote:
> > All -
> >
> > Ralph and I talked today about the logistics of bringing the OpenSHMEM
> > code to the 1.7 release branch, as it's now a fairly large set of changes
> > from the trunk.  What we propose is to follow the same proceedure we used
> > when merging in the RTE framework change, which is essentially a staging
> > branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> > bring the OpenSHMEM changes into that (and hopefully test), and then file
> > a single CMR for the changes from the branch.  If done properly, the GK
> > then only has to merge with --reintegrate and we're set.
> >
> > Let's talk about it on the call tomorrow, but that's the current
> proposal.
> >
> > Brian
> >
> > --
> >   Brian W. Barrett
> >   Scalable System Software Group
> >   Sandia National Laboratories
> >
> >
> >
> >
> > ___
> > 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
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

Re: [OMPI devel] SHMEM v1.7 merge proposal

2013-10-29 Thread Jeff Squyres (jsquyres) 
I'm not sure what you mean.

Brian's proposal was that y'all the shmem stuff go into a single SVN branch off 
the v1.7 branch. This way, it can be reviewed properly and easily merged into 
the actual v1.7 SVN branch.

Sent from my phone. No type good.
On Oct 29, 2013, at 7:09 AM, "Mike Dubman" 
mailto:mi...@dev.mellanox.co.il>> wrote:

will it be ok, that once all is ready, we push git2svn branch for this?


On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) 
mailto:jsquy...@cisco.com>> wrote:
I think Brian's point is that it should be a SVN branch.


On Oct 29, 2013, at 3:27 AM, Mike Dubman 
mailto:mi...@dev.mellanox.co.il>> wrote:

> Hi,
> This is exactly the way we handle it now. We have internal branch on top of 
> v1.7 with all SHMEM code in it.
> It runs mtt and other tests.
>
> Once we done with all changes - we will provide patch (and branch direct 
> access if needed) for GK.
>
> Kind Regards
> Mike.
>
>
> On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W 
> mailto:bwba...@sandia.gov>> wrote:
> All -
>
> Ralph and I talked today about the logistics of bringing the OpenSHMEM
> code to the 1.7 release branch, as it's now a fairly large set of changes
> from the trunk.  What we propose is to follow the same proceedure we used
> when merging in the RTE framework change, which is essentially a staging
> branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> bring the OpenSHMEM changes into that (and hopefully test), and then file
> a single CMR for the changes from the branch.  If done properly, the GK
> then only has to merge with --reintegrate and we're set.
>
> Let's talk about it on the call tomorrow, but that's the current proposal.
>
> Brian
>
> --
>   Brian W. Barrett
>   Scalable System Software Group
>   Sandia National Laboratories
>
>
>
>
> ___
> 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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
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] SHMEM v1.7 merge proposal

2013-10-29 Thread Jeff Squyres (jsquyres) 
On Oct 29, 2013, at 7:16 AM, "Jeff Squyres (jsquyres)"  
wrote:

> ...that y'all the shmem stuff...

I guess this is what happens when you buy an iPhone in Kentucky.

DYAC!

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] SHMEM v1.7 merge proposal

2013-10-29 Thread Joshua Ladd 
I wondered where that was coming from.


-Original Message-
From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres 
(jsquyres)
Sent: Tuesday, October 29, 2013 7:53 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] SHMEM v1.7 merge proposal

On Oct 29, 2013, at 7:16 AM, "Jeff Squyres (jsquyres)"  
wrote:

> ...that y'all the shmem stuff...

I guess this is what happens when you buy an iPhone in Kentucky.

DYAC!

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal

2013-10-29 Thread Barrett, Brian W 
1) thanks for jumping in before I woke up
2) y'all? You've been in Kentucky too long :)

Brian



Sent with Good (www.good.com)


-Original Message-
From: Jeff Squyres (jsquyres) [jsquy...@cisco.com]
Sent: Tuesday, October 29, 2013 05:17 AM Mountain Standard Time
To: Open MPI Developers
Subject: [EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal

I'm not sure what you mean.

Brian's proposal was that y'all the shmem stuff go into a single SVN branch off 
the v1.7 branch. This way, it can be reviewed properly and easily merged into 
the actual v1.7 SVN branch.

Sent from my phone. No type good.
On Oct 29, 2013, at 7:09 AM, "Mike Dubman" 
mailto:mi...@dev.mellanox.co.il>> wrote:

will it be ok, that once all is ready, we push git2svn branch for this?


On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) 
mailto:jsquy...@cisco.com>> wrote:
I think Brian's point is that it should be a SVN branch.


On Oct 29, 2013, at 3:27 AM, Mike Dubman 
mailto:mi...@dev.mellanox.co.il>> wrote:

> Hi,
> This is exactly the way we handle it now. We have internal branch on top of 
> v1.7 with all SHMEM code in it.
> It runs mtt and other tests.
>
> Once we done with all changes - we will provide patch (and branch direct 
> access if needed) for GK.
>
> Kind Regards
> Mike.
>
>
> On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W 
> mailto:bwba...@sandia.gov>> wrote:
> All -
>
> Ralph and I talked today about the logistics of bringing the OpenSHMEM
> code to the 1.7 release branch, as it's now a fairly large set of changes
> from the trunk.  What we propose is to follow the same proceedure we used
> when merging in the RTE framework change, which is essentially a staging
> branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> bring the OpenSHMEM changes into that (and hopefully test), and then file
> a single CMR for the changes from the branch.  If done properly, the GK
> then only has to merge with --reintegrate and we're set.
>
> Let's talk about it on the call tomorrow, but that's the current proposal.
>
> Brian
>
> --
>   Brian W. Barrett
>   Scalable System Software Group
>   Sandia National Laboratories
>
>
>
>
> ___
> 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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
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] [EXTERNAL] Re: SHMEM v1.7 merge proposal

2013-10-29 Thread Barrett, Brian W 
Yes, what's important is that 1) we all have a way to review the final merge 
(which means a public branch) and 2) it's easy for the GK to merge.

Brian



Sent with Good (www.good.com)


-Original Message-
From: Jeff Squyres (jsquyres) [jsquy...@cisco.com]
Sent: Tuesday, October 29, 2013 04:36 AM Mountain Standard Time
To: Open MPI Developers
Subject: [EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal


I think Brian's point is that it should be a SVN branch.


On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:

> Hi,
> This is exactly the way we handle it now. We have internal branch on top of 
> v1.7 with all SHMEM code in it.
> It runs mtt and other tests.
>
> Once we done with all changes - we will provide patch (and branch direct 
> access if needed) for GK.
>
> Kind Regards
> Mike.
>
>
> On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W  wrote:
> All -
>
> Ralph and I talked today about the logistics of bringing the OpenSHMEM
> code to the 1.7 release branch, as it's now a fairly large set of changes
> from the trunk.  What we propose is to follow the same proceedure we used
> when merging in the RTE framework change, which is essentially a staging
> branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> bring the OpenSHMEM changes into that (and hopefully test), and then file
> a single CMR for the changes from the branch.  If done properly, the GK
> then only has to merge with --reintegrate and we're set.
>
> Let's talk about it on the call tomorrow, but that's the current proposal.
>
> Brian
>
> --
>   Brian W. Barrett
>   Scalable System Software Group
>   Sandia National Laboratories
>
>
>
>
> ___
> 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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal

2013-10-29 Thread Joshua Ladd 
I think the community’s concerns are valid. What Mike is articulating is that 
we already maintain a “1.7 ready” OSHMEM branch internally. I think it should 
be a simple procedure to do as Brian and Ralph are suggesting and branch off of 
1.7 in SVN and apply our patches. We can do this.

Josh

From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Barrett, Brian W
Sent: Tuesday, October 29, 2013 9:29 AM
To: 'Open MPI Developers'; 'Open MPI Developers'
Subject: Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal

Yes, what's important is that 1) we all have a way to review the final merge 
(which means a public branch) and 2) it's easy for the GK to merge.

Brian



Sent with Good (www.good.com)


-Original Message-
From: Jeff Squyres (jsquyres) [jsquy...@cisco.com]
Sent: Tuesday, October 29, 2013 04:36 AM Mountain Standard Time
To: Open MPI Developers
Subject: [EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal



I think Brian's point is that it should be a SVN branch.


On Oct 29, 2013, at 3:27 AM, Mike Dubman 
mailto:mi...@dev.mellanox.co.il>> wrote:

> Hi,
> This is exactly the way we handle it now. We have internal branch on top of 
> v1.7 with all SHMEM code in it.
> It runs mtt and other tests.
>
> Once we done with all changes - we will provide patch (and branch direct 
> access if needed) for GK.
>
> Kind Regards
> Mike.
>
>
> On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W 
> mailto:bwba...@sandia.gov>> wrote:
> All -
>
> Ralph and I talked today about the logistics of bringing the OpenSHMEM
> code to the 1.7 release branch, as it's now a fairly large set of changes
> from the trunk.  What we propose is to follow the same proceedure we used
> when merging in the RTE framework change, which is essentially a staging
> branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> bring the OpenSHMEM changes into that (and hopefully test), and then file
> a single CMR for the changes from the branch.  If done properly, the GK
> then only has to merge with --reintegrate and we're set.
>
> Let's talk about it on the call tomorrow, but that's the current proposal.
>
> Brian
>
> --
>   Brian W. Barrett
>   Scalable System Software Group
>   Sandia National Laboratories
>
>
>
>
> ___
> 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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal

2013-10-29 Thread Mike Dubman 
yes, this is what I tried to suggest :)
we export our git branch to svn in openmpi.org for review.


On Tue, Oct 29, 2013 at 3:34 PM, Joshua Ladd  wrote:

>  I think the community’s concerns are valid. What Mike is articulating is
> that we already maintain a “1.7 ready” OSHMEM branch internally. I think it
> should be a simple procedure to do as Brian and Ralph are suggesting and
> branch off of 1.7 in SVN and apply our patches. We can do this.
>
> ** **
>
> Josh  
>
> ** **
>
> *From:* devel [mailto:devel-boun...@open-mpi.org] *On Behalf Of *Barrett,
> Brian W
> *Sent:* Tuesday, October 29, 2013 9:29 AM
> *To:* 'Open MPI Developers'; 'Open MPI Developers'
> *Subject:* Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal
>
> ** **
>
> Yes, what's important is that 1) we all have a way to review the final
> merge (which means a public branch) and 2) it's easy for the GK to merge.
>
> Brian
>
>
>
> Sent with Good (www.good.com)
>
>
> -Original Message-
> *From: *Jeff Squyres (jsquyres) [jsquy...@cisco.com]
> *Sent: *Tuesday, October 29, 2013 04:36 AM Mountain Standard Time
> *To: *Open MPI Developers
> *Subject: *[EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal
>
>
> 
>
> I think Brian's point is that it should be a SVN branch.
>
>
> On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:
>
> > Hi,
> > This is exactly the way we handle it now. We have internal branch on top
> of v1.7 with all SHMEM code in it.
> > It runs mtt and other tests.
> >
> > Once we done with all changes - we will provide patch (and branch direct
> access if needed) for GK.
> >
> > Kind Regards
> > Mike.
> >
> >
> > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W 
> wrote:
> > All -
> >
> > Ralph and I talked today about the logistics of bringing the OpenSHMEM
> > code to the 1.7 release branch, as it's now a fairly large set of changes
> > from the trunk.  What we propose is to follow the same proceedure we used
> > when merging in the RTE framework change, which is essentially a staging
> > branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> > bring the OpenSHMEM changes into that (and hopefully test), and then file
> > a single CMR for the changes from the branch.  If done properly, the GK
> > then only has to merge with --reintegrate and we're set.
> >
> > Let's talk about it on the call tomorrow, but that's the current
> proposal.
> >
> > Brian
> >
> > --
> >   Brian W. Barrett
> >   Scalable System Software Group
> >   Sandia National Laboratories
> >
> >
> >
> >
> > ___
> > 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
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> 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] [EXTERNAL] Re: SHMEM v1.7 merge proposal

2013-10-29 Thread Ralph Castain 
That would be fine - thanks!

When you do the export, please setup the "svn ignore" properties after you do 
your test build. Those don't get set by git, of course.


On Oct 29, 2013, at 7:28 AM, Mike Dubman  wrote:

> yes, this is what I tried to suggest :)
> we export our git branch to svn in openmpi.org for review.
> 
> 
> On Tue, Oct 29, 2013 at 3:34 PM, Joshua Ladd  wrote:
> I think the community’s concerns are valid. What Mike is articulating is that 
> we already maintain a “1.7 ready” OSHMEM branch internally. I think it should 
> be a simple procedure to do as Brian and Ralph are suggesting and branch off 
> of 1.7 in SVN and apply our patches. We can do this.
> 
>  
> 
> Josh  
> 
>  
> 
> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Barrett, Brian W
> Sent: Tuesday, October 29, 2013 9:29 AM
> To: 'Open MPI Developers'; 'Open MPI Developers'
> Subject: Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal
> 
>  
> 
> Yes, what's important is that 1) we all have a way to review the final merge 
> (which means a public branch) and 2) it's easy for the GK to merge.
> 
> Brian
> 
> 
> 
> Sent with Good (www.good.com)
> 
> 
> -Original Message-
> From: Jeff Squyres (jsquyres) [jsquy...@cisco.com]
> Sent: Tuesday, October 29, 2013 04:36 AM Mountain Standard Time
> To: Open MPI Developers
> Subject: [EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal
> 
> 
> 
> I think Brian's point is that it should be a SVN branch.
> 
> 
> On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:
> 
> > Hi,
> > This is exactly the way we handle it now. We have internal branch on top of 
> > v1.7 with all SHMEM code in it.
> > It runs mtt and other tests.
> >
> > Once we done with all changes - we will provide patch (and branch direct 
> > access if needed) for GK.
> >
> > Kind Regards
> > Mike.
> >
> >
> > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W  
> > wrote:
> > All -
> >
> > Ralph and I talked today about the logistics of bringing the OpenSHMEM
> > code to the 1.7 release branch, as it's now a fairly large set of changes
> > from the trunk.  What we propose is to follow the same proceedure we used
> > when merging in the RTE framework change, which is essentially a staging
> > branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> > bring the OpenSHMEM changes into that (and hopefully test), and then file
> > a single CMR for the changes from the branch.  If done properly, the GK
> > then only has to merge with --reintegrate and we're set.
> >
> > Let's talk about it on the call tomorrow, but that's the current proposal.
> >
> > Brian
> >
> > --
> >   Brian W. Barrett
> >   Scalable System Software Group
> >   Sandia National Laboratories
> >
> >
> >
> >
> > ___
> > 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
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> 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
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] SHMEM v1.7 merge proposal

2013-10-29 Thread Dave Goodell (dgoodell) 
Mike,

I've never personally used git2svn, but my understanding is that it would 
require us to essentially "lock" the repository to all other commits while you 
are using it, which isn't very friendly to the rest of the community.  Also, 
using git2svn probably wouldn't twiddle the SVN merge tracking metadata 
correctly.

I think it would be better to simply handle this with "svn merge" and friends.

-Dave

On Oct 29, 2013, at 6:08 AM, Mike Dubman  wrote:

> will it be ok, that once all is ready, we push git2svn branch for this?
> 
> 
> On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) 
>  wrote:
> I think Brian's point is that it should be a SVN branch.
> 
> 
> On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:
> 
> > Hi,
> > This is exactly the way we handle it now. We have internal branch on top of 
> > v1.7 with all SHMEM code in it.
> > It runs mtt and other tests.
> >
> > Once we done with all changes - we will provide patch (and branch direct 
> > access if needed) for GK.
> >
> > Kind Regards
> > Mike.
> >
> >
> > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W  
> > wrote:
> > All -
> >
> > Ralph and I talked today about the logistics of bringing the OpenSHMEM
> > code to the 1.7 release branch, as it's now a fairly large set of changes
> > from the trunk.  What we propose is to follow the same proceedure we used
> > when merging in the RTE framework change, which is essentially a staging
> > branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> > bring the OpenSHMEM changes into that (and hopefully test), and then file
> > a single CMR for the changes from the branch.  If done properly, the GK
> > then only has to merge with --reintegrate and we're set.
> >
> > Let's talk about it on the call tomorrow, but that's the current proposal.
> >
> > Brian
> >
> > --
> >   Brian W. Barrett
> >   Scalable System Software Group
> >   Sandia National Laboratories
> >
> >
> >
> >
> > ___
> > 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
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> 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] SHMEM v1.7 merge proposal

2013-10-29 Thread Ralph Castain 
As I understood it, they would create a new 1.7 branch and use git2svn to merge 
into it - i.e., there would be a new 1.7 branch that had their changes in it. 
The GK could then use "reintegrate" to bring those changes into the official 
1.7 branch.


On Oct 29, 2013, at 7:41 AM, Dave Goodell (dgoodell)  wrote:

> Mike,
> 
> I've never personally used git2svn, but my understanding is that it would 
> require us to essentially "lock" the repository to all other commits while 
> you are using it, which isn't very friendly to the rest of the community.  
> Also, using git2svn probably wouldn't twiddle the SVN merge tracking metadata 
> correctly.
> 
> I think it would be better to simply handle this with "svn merge" and friends.
> 
> -Dave
> 
> On Oct 29, 2013, at 6:08 AM, Mike Dubman  wrote:
> 
>> will it be ok, that once all is ready, we push git2svn branch for this?
>> 
>> 
>> On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) 
>>  wrote:
>> I think Brian's point is that it should be a SVN branch.
>> 
>> 
>> On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:
>> 
>>> Hi,
>>> This is exactly the way we handle it now. We have internal branch on top of 
>>> v1.7 with all SHMEM code in it.
>>> It runs mtt and other tests.
>>> 
>>> Once we done with all changes - we will provide patch (and branch direct 
>>> access if needed) for GK.
>>> 
>>> Kind Regards
>>> Mike.
>>> 
>>> 
>>> On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W  
>>> wrote:
>>> All -
>>> 
>>> Ralph and I talked today about the logistics of bringing the OpenSHMEM
>>> code to the 1.7 release branch, as it's now a fairly large set of changes
>>> from the trunk.  What we propose is to follow the same proceedure we used
>>> when merging in the RTE framework change, which is essentially a staging
>>> branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
>>> bring the OpenSHMEM changes into that (and hopefully test), and then file
>>> a single CMR for the changes from the branch.  If done properly, the GK
>>> then only has to merge with --reintegrate and we're set.
>>> 
>>> Let's talk about it on the call tomorrow, but that's the current proposal.
>>> 
>>> Brian
>>> 
>>> --
>>>  Brian W. Barrett
>>>  Scalable System Software Group
>>>  Sandia National Laboratories
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> 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
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] SHMEM v1.7 merge proposal

2013-10-29 Thread Mike Dubman 
We probably will generate single patch with all changes applied in v1.7 for
shmem and create svn branch from 1.7 + patch.

Im sorry, did not mean we port git history from git to svn, it sounds
trouble.
Mike,

I've never personally used git2svn, but my understanding is that it would
require us to essentially "lock" the repository to all other commits while
you are using it, which isn't very friendly to the rest of the community.
 Also, using git2svn probably wouldn't twiddle the SVN merge tracking
metadata correctly.

I think it would be better to simply handle this with "svn merge" and
friends.

-Dave

On Oct 29, 2013, at 6:08 AM, Mike Dubman  wrote:

> will it be ok, that once all is ready, we push git2svn branch for this?
>
>
> On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
> I think Brian's point is that it should be a SVN branch.
>
>
> On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:
>
> > Hi,
> > This is exactly the way we handle it now. We have internal branch on
top of v1.7 with all SHMEM code in it.
> > It runs mtt and other tests.
> >
> > Once we done with all changes - we will provide patch (and branch
direct access if needed) for GK.
> >
> > Kind Regards
> > Mike.
> >
> >
> > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W 
wrote:
> > All -
> >
> > Ralph and I talked today about the logistics of bringing the OpenSHMEM
> > code to the 1.7 release branch, as it's now a fairly large set of
changes
> > from the trunk.  What we propose is to follow the same proceedure we
used
> > when merging in the RTE framework change, which is essentially a staging
> > branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
> > bring the OpenSHMEM changes into that (and hopefully test), and then
file
> > a single CMR for the changes from the branch.  If done properly, the GK
> > then only has to merge with --reintegrate and we're set.
> >
> > Let's talk about it on the call tomorrow, but that's the current
proposal.
> >
> > Brian
> >
> > --
> >   Brian W. Barrett
> >   Scalable System Software Group
> >   Sandia National Laboratories
> >
> >
> >
> >
> > ___
> > 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
> jsquy...@cisco.com
> For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> 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

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal

2013-10-29 Thread Jeff Squyres (jsquyres) 
+1 -- sounds good, thanks!

Just put the branch under /tmp; that's where we typically put short-lived 
branches.  E.g., http://svn.open-mpi.org/svn/ompi/tmp/oshmem-for-v1.7, or 
somesuch.


On Oct 29, 2013, at 10:31 AM, Ralph Castain  wrote:

> That would be fine - thanks!
> 
> When you do the export, please setup the "svn ignore" properties after you do 
> your test build. Those don't get set by git, of course.
> 
> 
> On Oct 29, 2013, at 7:28 AM, Mike Dubman  wrote:
> 
>> yes, this is what I tried to suggest :)
>> we export our git branch to svn in openmpi.org for review.
>> 
>> 
>> On Tue, Oct 29, 2013 at 3:34 PM, Joshua Ladd  wrote:
>> I think the community’s concerns are valid. What Mike is articulating is 
>> that we already maintain a “1.7 ready” OSHMEM branch internally. I think it 
>> should be a simple procedure to do as Brian and Ralph are suggesting and 
>> branch off of 1.7 in SVN and apply our patches. We can do this.
>> 
>>  
>> 
>> Josh  
>> 
>>  
>> 
>> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Barrett, Brian W
>> Sent: Tuesday, October 29, 2013 9:29 AM
>> To: 'Open MPI Developers'; 'Open MPI Developers'
>> Subject: Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal
>> 
>>  
>> 
>> Yes, what's important is that 1) we all have a way to review the final merge 
>> (which means a public branch) and 2) it's easy for the GK to merge.
>> 
>> Brian
>> 
>> 
>> 
>> Sent with Good (www.good.com)
>> 
>> 
>> -Original Message-
>> From: Jeff Squyres (jsquyres) [jsquy...@cisco.com]
>> Sent: Tuesday, October 29, 2013 04:36 AM Mountain Standard Time
>> To: Open MPI Developers
>> Subject: [EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal
>> 
>> 
>> 
>> I think Brian's point is that it should be a SVN branch.
>> 
>> 
>> On Oct 29, 2013, at 3:27 AM, Mike Dubman  wrote:
>> 
>> > Hi,
>> > This is exactly the way we handle it now. We have internal branch on top 
>> > of v1.7 with all SHMEM code in it.
>> > It runs mtt and other tests.
>> >
>> > Once we done with all changes - we will provide patch (and branch direct 
>> > access if needed) for GK.
>> >
>> > Kind Regards
>> > Mike.
>> >
>> >
>> > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W  
>> > wrote:
>> > All -
>> >
>> > Ralph and I talked today about the logistics of bringing the OpenSHMEM
>> > code to the 1.7 release branch, as it's now a fairly large set of changes
>> > from the trunk.  What we propose is to follow the same proceedure we used
>> > when merging in the RTE framework change, which is essentially a staging
>> > branch.  So, Mellanox (as the one filing the CMR) would branch from 1.7,
>> > bring the OpenSHMEM changes into that (and hopefully test), and then file
>> > a single CMR for the changes from the branch.  If done properly, the GK
>> > then only has to merge with --reintegrate and we're set.
>> >
>> > Let's talk about it on the call tomorrow, but that's the current proposal.
>> >
>> > Brian
>> >
>> > --
>> >   Brian W. Barrett
>> >   Scalable System Software Group
>> >   Sandia National Laboratories
>> >
>> >
>> >
>> >
>> > ___
>> > 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
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> 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
>> 
>> ___
>> 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
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[OMPI devel] CM PML / OpenSHMEM

2013-10-29 Thread Barrett, Brian W 
Mellanox -

It looks like someone fixed the segfault when calling start_pes() when the
CM PML is in use.  However, I'm not sure that a clean abort is much
better.  With the proc tags code (in both the trunk and v1.7), there's no
reason that you can't initialize both the btls and mtls.  This may require
some additional coding, but I think it should be doable.  I'm happy to
help with advice / discuss implementation issues, but not supporting
OpenSHMEM when the CM PML is in use is unacceptable and is, in my mind, a
blocker for v1.7.

Brian

--
  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories

Re: [OMPI devel] CM PML / OpenSHMEM

2013-10-29 Thread Ralph Castain 
I think the issue that may have caused this was the need for a double modex if 
the MPI layer selected a PML that used an MTL, and then the user provided 
oshmem MCA params specifying they use the BTL-related SPML component. My guess 
is that the defaults wound up creating that situation, which then led to the 
clean abort.

Probably just a question of correctly setting defaults in the CM scenario.

On Oct 29, 2013, at 10:02 AM, Barrett, Brian W  wrote:

> Mellanox -
> 
> It looks like someone fixed the segfault when calling start_pes() when the
> CM PML is in use.  However, I'm not sure that a clean abort is much
> better.  With the proc tags code (in both the trunk and v1.7), there's no
> reason that you can't initialize both the btls and mtls.  This may require
> some additional coding, but I think it should be doable.  I'm happy to
> help with advice / discuss implementation issues, but not supporting
> OpenSHMEM when the CM PML is in use is unacceptable and is, in my mind, a
> blocker for v1.7.
> 
> Brian
> 
> --
>  Brian W. Barrett
>  Scalable System Software Group
>  Sandia National Laboratories
> 
> 
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] CM PML / OpenSHMEM

2013-10-29 Thread Joshua Ladd 
These (and others) are exactly the issues we need to discuss with you guys next 
week. 

Josh

-Original Message-
From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
Sent: Tuesday, October 29, 2013 1:29 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] CM PML / OpenSHMEM

I think the issue that may have caused this was the need for a double modex if 
the MPI layer selected a PML that used an MTL, and then the user provided 
oshmem MCA params specifying they use the BTL-related SPML component. My guess 
is that the defaults wound up creating that situation, which then led to the 
clean abort.

Probably just a question of correctly setting defaults in the CM scenario.

On Oct 29, 2013, at 10:02 AM, Barrett, Brian W  wrote:

> Mellanox -
> 
> It looks like someone fixed the segfault when calling start_pes() when 
> the CM PML is in use.  However, I'm not sure that a clean abort is 
> much better.  With the proc tags code (in both the trunk and v1.7), 
> there's no reason that you can't initialize both the btls and mtls.  
> This may require some additional coding, but I think it should be 
> doable.  I'm happy to help with advice / discuss implementation 
> issues, but not supporting OpenSHMEM when the CM PML is in use is 
> unacceptable and is, in my mind, a blocker for v1.7.
> 
> Brian
> 
> --
>  Brian W. Barrett
>  Scalable System Software Group
>  Sandia National Laboratories
> 
> 
> 
> 
> ___
> 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] CM PML / OpenSHMEM

2013-10-29 Thread Ralph Castain 
Did that time get finalized? I recall the doodle, but not seeing a final 
decision

On Oct 29, 2013, at 10:53 AM, Joshua Ladd  wrote:

> These (and others) are exactly the issues we need to discuss with you guys 
> next week. 
> 
> Josh
> 
> -Original Message-
> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
> Sent: Tuesday, October 29, 2013 1:29 PM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] CM PML / OpenSHMEM
> 
> I think the issue that may have caused this was the need for a double modex 
> if the MPI layer selected a PML that used an MTL, and then the user provided 
> oshmem MCA params specifying they use the BTL-related SPML component. My 
> guess is that the defaults wound up creating that situation, which then led 
> to the clean abort.
> 
> Probably just a question of correctly setting defaults in the CM scenario.
> 
> On Oct 29, 2013, at 10:02 AM, Barrett, Brian W  wrote:
> 
>> Mellanox -
>> 
>> It looks like someone fixed the segfault when calling start_pes() when 
>> the CM PML is in use.  However, I'm not sure that a clean abort is 
>> much better.  With the proc tags code (in both the trunk and v1.7), 
>> there's no reason that you can't initialize both the btls and mtls.  
>> This may require some additional coding, but I think it should be 
>> doable.  I'm happy to help with advice / discuss implementation 
>> issues, but not supporting OpenSHMEM when the CM PML is in use is 
>> unacceptable and is, in my mind, a blocker for v1.7.
>> 
>> Brian
>> 
>> --
>> Brian W. Barrett
>> Scalable System Software Group
>> Sandia National Laboratories
>> 
>> 
>> 
>> 
>> ___
>> 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
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] CM PML / OpenSHMEM

2013-10-29 Thread Joshua Ladd 
I knew someone was going to ask :)

Mike asked me to add 2pm EST to the times listed.  Can you guys go and update 
those boxes? It looks like Thursday 2pm EST is our best shot at convergence. 

-Original Message-
From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
Sent: Tuesday, October 29, 2013 1:58 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] CM PML / OpenSHMEM

Did that time get finalized? I recall the doodle, but not seeing a final 
decision

On Oct 29, 2013, at 10:53 AM, Joshua Ladd  wrote:

> These (and others) are exactly the issues we need to discuss with you guys 
> next week. 
> 
> Josh
> 
> -Original Message-
> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph 
> Castain
> Sent: Tuesday, October 29, 2013 1:29 PM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] CM PML / OpenSHMEM
> 
> I think the issue that may have caused this was the need for a double modex 
> if the MPI layer selected a PML that used an MTL, and then the user provided 
> oshmem MCA params specifying they use the BTL-related SPML component. My 
> guess is that the defaults wound up creating that situation, which then led 
> to the clean abort.
> 
> Probably just a question of correctly setting defaults in the CM scenario.
> 
> On Oct 29, 2013, at 10:02 AM, Barrett, Brian W  wrote:
> 
>> Mellanox -
>> 
>> It looks like someone fixed the segfault when calling start_pes() 
>> when the CM PML is in use.  However, I'm not sure that a clean abort 
>> is much better.  With the proc tags code (in both the trunk and 
>> v1.7), there's no reason that you can't initialize both the btls and mtls.
>> This may require some additional coding, but I think it should be 
>> doable.  I'm happy to help with advice / discuss implementation 
>> issues, but not supporting OpenSHMEM when the CM PML is in use is 
>> unacceptable and is, in my mind, a blocker for v1.7.
>> 
>> Brian
>> 
>> --
>> Brian W. Barrett
>> Scalable System Software Group
>> Sandia National Laboratories
>> 
>> 
>> 
>> 
>> ___
>> 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
> ___
> 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] CM PML / OpenSHMEM

2013-10-29 Thread Jeff Squyres (jsquyres) 
What was the doodle link again?

On Oct 29, 2013, at 2:19 PM, Joshua Ladd  wrote:

> I knew someone was going to ask :)
> 
> Mike asked me to add 2pm EST to the times listed.  Can you guys go and update 
> those boxes? It looks like Thursday 2pm EST is our best shot at convergence. 
> 
> -Original Message-
> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
> Sent: Tuesday, October 29, 2013 1:58 PM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] CM PML / OpenSHMEM
> 
> Did that time get finalized? I recall the doodle, but not seeing a final 
> decision
> 
> On Oct 29, 2013, at 10:53 AM, Joshua Ladd  wrote:
> 
>> These (and others) are exactly the issues we need to discuss with you guys 
>> next week. 
>> 
>> Josh
>> 
>> -Original Message-
>> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph 
>> Castain
>> Sent: Tuesday, October 29, 2013 1:29 PM
>> To: Open MPI Developers
>> Subject: Re: [OMPI devel] CM PML / OpenSHMEM
>> 
>> I think the issue that may have caused this was the need for a double modex 
>> if the MPI layer selected a PML that used an MTL, and then the user provided 
>> oshmem MCA params specifying they use the BTL-related SPML component. My 
>> guess is that the defaults wound up creating that situation, which then led 
>> to the clean abort.
>> 
>> Probably just a question of correctly setting defaults in the CM scenario.
>> 
>> On Oct 29, 2013, at 10:02 AM, Barrett, Brian W  wrote:
>> 
>>> Mellanox -
>>> 
>>> It looks like someone fixed the segfault when calling start_pes() 
>>> when the CM PML is in use.  However, I'm not sure that a clean abort 
>>> is much better.  With the proc tags code (in both the trunk and 
>>> v1.7), there's no reason that you can't initialize both the btls and mtls.
>>> This may require some additional coding, but I think it should be 
>>> doable.  I'm happy to help with advice / discuss implementation 
>>> issues, but not supporting OpenSHMEM when the CM PML is in use is 
>>> unacceptable and is, in my mind, a blocker for v1.7.
>>> 
>>> Brian
>>> 
>>> --
>>> Brian W. Barrett
>>> Scalable System Software Group
>>> Sandia National Laboratories
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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
>> ___
>> 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
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] CM PML / OpenSHMEM

2013-10-29 Thread Ralph Castain 
I don't have the doodle link, but fwiw, that time is fine with me.

On Oct 29, 2013, at 11:25 AM, Jeff Squyres (jsquyres)  
wrote:

> What was the doodle link again?
> 
> On Oct 29, 2013, at 2:19 PM, Joshua Ladd  wrote:
> 
>> I knew someone was going to ask :)
>> 
>> Mike asked me to add 2pm EST to the times listed.  Can you guys go and 
>> update those boxes? It looks like Thursday 2pm EST is our best shot at 
>> convergence. 
>> 
>> -Original Message-
>> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
>> Sent: Tuesday, October 29, 2013 1:58 PM
>> To: Open MPI Developers
>> Subject: Re: [OMPI devel] CM PML / OpenSHMEM
>> 
>> Did that time get finalized? I recall the doodle, but not seeing a final 
>> decision
>> 
>> On Oct 29, 2013, at 10:53 AM, Joshua Ladd  wrote:
>> 
>>> These (and others) are exactly the issues we need to discuss with you guys 
>>> next week. 
>>> 
>>> Josh
>>> 
>>> -Original Message-
>>> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph 
>>> Castain
>>> Sent: Tuesday, October 29, 2013 1:29 PM
>>> To: Open MPI Developers
>>> Subject: Re: [OMPI devel] CM PML / OpenSHMEM
>>> 
>>> I think the issue that may have caused this was the need for a double modex 
>>> if the MPI layer selected a PML that used an MTL, and then the user 
>>> provided oshmem MCA params specifying they use the BTL-related SPML 
>>> component. My guess is that the defaults wound up creating that situation, 
>>> which then led to the clean abort.
>>> 
>>> Probably just a question of correctly setting defaults in the CM scenario.
>>> 
>>> On Oct 29, 2013, at 10:02 AM, Barrett, Brian W  wrote:
>>> 
 Mellanox -
 
 It looks like someone fixed the segfault when calling start_pes() 
 when the CM PML is in use.  However, I'm not sure that a clean abort 
 is much better.  With the proc tags code (in both the trunk and 
 v1.7), there's no reason that you can't initialize both the btls and mtls.
 This may require some additional coding, but I think it should be 
 doable.  I'm happy to help with advice / discuss implementation 
 issues, but not supporting OpenSHMEM when the CM PML is in use is 
 unacceptable and is, in my mind, a blocker for v1.7.
 
 Brian
 
 --
 Brian W. Barrett
 Scalable System Software Group
 Sandia National Laboratories
 
 
 
 
 ___
 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
>>> ___
>>> 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
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel