date:20131212

Re: [OMPI devel] iWARP development

2013-12-12 Thread Jeff Squyres (jsquyres)

On Dec 12, 2013, at 4:31 PM, "Prindeville, Philip"  
wrote:

> I think I understand.
>  
> I’ll pull a copy of trunk and dig around in there.
>  
> Is there a reason that the code can’t be gated by conditional compilation 
> flags or detect the environment at run-time?

I'm not sure what you're asking -- we have a bunch of code that is gated on 
#if's, and we have a lot of auto-detection at run-time.  That's kinda OMPI's 
mantra: look around the system at run time and use what it finds.  Meaning: I 
think what you're suggesting is already fairly common practice in this 
community.

Are you thinking of modifying the openib BTL to do more things with SCTP as a 
lower-layer transport for iWARP (under verbs)?  To do so, you'll need to go 
outside the verbs API -- is that correct?

I'll warn you that the openib BTL is fairly complex.  :-)  Indeed, if you want 
an iWARP+SCTP-specific transport, it *might* be worthwhile to do your own 
BTL...?  You might even be able to use openib as a starting point, strip out 
everything that iWARP doesn't need (i.e., all the IB/RoCE-specific stuff), have 
something quite a bit simpler than openib, and then add your SCTP stuff on 
that...?  Just an idle thought.

Note that if you're going to contribute code back to Open MPI, we'll need a 
signed contributor's agreement (see 
http://www.open-mpi.org/community/contribute/).

> Is there anything in the way of a set of verification tests?  

We typically just use lots of standard MPI tests and benchmarks.

> And what’s the provenance of the SCTP code that’s in trunk?

It was originally written by U. British Columbia.  It doesn't use iWARP at all. 
 It also hasn't been maintained in quite a while -- I can't honestly say what 
its current state is (which is one of the reasons it was removed from the v1.7 
release branch).

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

Re: [OMPI devel] iWARP development

2013-12-12 Thread Ralph Castain

We already have conditional compilation there at configure time (see
ompi/mca/btl/sctp/configure.m4) so it won't built unless requested.
Likewise, you can use the MCA params to select to use it or not (-mca btl
sctp,sm,self).

I'm not aware of any sctp-specific tests. However, there are lots of simple
MPI tests you could run that would test it as a BTL - anything that would
exchange data across nodes, for example.

Nobody has spoken up to "own" the sctp btl at this time, so I think you'd
have a pretty free hand with it (subject to our usual critique to ensure
consistency across the BTLs).



On Thu, Dec 12, 2013 at 4:31 PM, Prindeville, Philip <
philip.prindevi...@hp.com> wrote:

>  I think I understand.
>
>
>
> I’ll pull a copy of trunk and dig around in there.
>
>
>
> Is there a reason that the code can’t be gated by conditional compilation
> flags or detect the environment at run-time?
>
>
>
> Is there anything in the way of a set of verification tests?  And what’s
> the provenance of the SCTP code that’s in trunk?
>
>
>
> Thanks,
>
>
>
> -Philip
>
>
>
>
>
> *From:* devel [mailto:devel-boun...@open-mpi.org] *On Behalf Of *Ralph
> Castain
> *Sent:* Thursday, December 12, 2013 8:41 AM
> *To:* Open MPI Developers
>
> *Subject:* Re: [OMPI devel] iWARP development
>
>
>
> Be aware that we removed SCTP from the 1.7 release series because of its
> unknown state of repair - I don't believe anyone has tested it in quite
> some time, and nobody has been maintaining it so far as we know. Not saying
> it won't work - just saying that I don't think we know :-/
>
>
>
> On Wed, Dec 11, 2013 at 6:07 PM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
>
> On Dec 11, 2013, at 5:33 PM, "Prindeville, Philip" <
> philip.prindevi...@hp.com> wrote:
>
> > I was wondering what the current state of iWARP development is.
>
> Open MPI's iWARP support is part of the "openib" BTL (so named because
> OpenFabrics used to be known as OpenIB, before iWARP joined, and we never
> changed the name of our plugin after OFA became OFA).
>
>
> > There are some features we’re interested in, and from what I can tell
> the iWARP RFCs/Internet Drafts haven’t caught up to related developments.
>
> As George mentioned, we deleted the SCTP plugin from the 1.7 release
> branch -- but that's a standalone SCTP plugin, which is not what I think
> you're asking about it.
>
>
> > Part of our interest is in using SCTP as the LLP for iWARP, and updating
> that adaptation to the latest SCTP work.
>
> Gotcha.
>
>
> > For instance:
> >
> > RFC 6458 – SCTP authentication
> > RFC 6458 – SCTP out-of-order delivery
> > RFC 6458 – SCTP association end-point address changes
> > RFC 6458 – SCTP Receive Information
> > RFC 6458 – SCTP partially reliable delivery
> > RFC 6458 – SCTP key management
> > RFC 5061 – SCTP Dynamic address reconfiguration (useful for hot NIC
> swaps in a high availability environment)
> >
> > We’d also like to see load-sharing in multipath environments, and
> sender-side traffic shaping support.
>
> Sounds nifty.
>
>
> > From what I can tell, the iWARP SCTP work that’s been done predates
> RFC-6458, and hence I’m assuming it’s aligned to RFC-5043.
>
> Sure...?
>
>
> > Other questions I have:
> >
> > Has this code been tested extensively on non-x86 platforms?  What about
> IA64, PPC64, ARM7, or MIPS 7K?
>
> Doubtful.  The openib BTL is known to work with IB and iWARP on a variety
> of x86 platforms.  I have no idea, and would kinda doubt, if it has been
> tested on any of the other platforms you've specified.
>
>
> > Is anyone doing any code to port SolarFlare OpenOnload stack to support
> Open MPI’s iWARP?
>
> Nope.  SF has told me/others that they're happy just doing their onload
> TCP through OMPI -- they don't see the need to do their own OO plugin (but
> don't take my word for it; I certainly cannot speak for them -- feel free
> to ask them yourself).
>
>
> > And a minor note… Just looking at the 1.7.3 tarball and grepping for
> SCTP in it, I find only a few matches, such as this:
> >
> > evutil_getaddrinfo_infer_protocols(struct evutil_addrinfo *hints)
> > {
> > …
> > #ifdef IPPROTO_SCTP
> > else if (hints->ai_protocol ==
> IPPROTO_SCTP)
> > hints->ai_socktype =
> SOCK_STREAM;
> > #endif
> > }
> > }
> >
> > And this has me puzzled: SCTP is predominately a SOCK_SEQPACKET, isn’t
> it? (The whole point of using it and not TCP as a transport is it preserves
> record boundaries, supports out-of-order delivery and message interleaving,
> etc.)
> >
> > At least, that’s how it registers itself as a protocol in Linux 3.12 in
> net/sctp/protocol.c …
> >
> > Apologies if there’s a better mailing list for iWARP specific questions.
> I’m looking at a lot of this stuff for the first time and having to ramp up
> quickly.
> >
> > Thanks,
> >
> > -Philip
> >
> >
>
> > ___
> > devel mailing list
> >

Re: [OMPI devel] iWARP development

2013-12-12 Thread Prindeville, Philip

I think I understand.

I'll pull a copy of trunk and dig around in there.

Is there a reason that the code can't be gated by conditional compilation flags 
or detect the environment at run-time?

Is there anything in the way of a set of verification tests?  And what's the 
provenance of the SCTP code that's in trunk?

Thanks,

-Philip


From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
Sent: Thursday, December 12, 2013 8:41 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] iWARP development

Be aware that we removed SCTP from the 1.7 release series because of its 
unknown state of repair - I don't believe anyone has tested it in quite some 
time, and nobody has been maintaining it so far as we know. Not saying it won't 
work - just saying that I don't think we know :-/

On Wed, Dec 11, 2013 at 6:07 PM, Jeff Squyres (jsquyres) 
> wrote:
On Dec 11, 2013, at 5:33 PM, "Prindeville, Philip" 
> wrote:

> I was wondering what the current state of iWARP development is.
Open MPI's iWARP support is part of the "openib" BTL (so named because 
OpenFabrics used to be known as OpenIB, before iWARP joined, and we never 
changed the name of our plugin after OFA became OFA).

> There are some features we're interested in, and from what I can tell the 
> iWARP RFCs/Internet Drafts haven't caught up to related developments.
As George mentioned, we deleted the SCTP plugin from the 1.7 release branch -- 
but that's a standalone SCTP plugin, which is not what I think you're asking 
about it.

> Part of our interest is in using SCTP as the LLP for iWARP, and updating that 
> adaptation to the latest SCTP work.
Gotcha.

> For instance:
>
> RFC 6458 - SCTP authentication
> RFC 6458 - SCTP out-of-order delivery
> RFC 6458 - SCTP association end-point address changes
> RFC 6458 - SCTP Receive Information
> RFC 6458 - SCTP partially reliable delivery
> RFC 6458 - SCTP key management
> RFC 5061 - SCTP Dynamic address reconfiguration (useful for hot NIC swaps in 
> a high availability environment)
>
> We'd also like to see load-sharing in multipath environments, and sender-side 
> traffic shaping support.
Sounds nifty.

> From what I can tell, the iWARP SCTP work that's been done predates RFC-6458, 
> and hence I'm assuming it's aligned to RFC-5043.
Sure...?

> Other questions I have:
>
> Has this code been tested extensively on non-x86 platforms?  What about IA64, 
> PPC64, ARM7, or MIPS 7K?
Doubtful.  The openib BTL is known to work with IB and iWARP on a variety of 
x86 platforms.  I have no idea, and would kinda doubt, if it has been tested on 
any of the other platforms you've specified.

> Is anyone doing any code to port SolarFlare OpenOnload stack to support Open 
> MPI's iWARP?
Nope.  SF has told me/others that they're happy just doing their onload TCP 
through OMPI -- they don't see the need to do their own OO plugin (but don't 
take my word for it; I certainly cannot speak for them -- feel free to ask them 
yourself).

> And a minor note... Just looking at the 1.7.3 tarball and grepping for SCTP 
> in it, I find only a few matches, such as this:
>
> evutil_getaddrinfo_infer_protocols(struct evutil_addrinfo *hints)
> {
> ...
> #ifdef IPPROTO_SCTP
> else if (hints->ai_protocol == IPPROTO_SCTP)
> hints->ai_socktype = 
> SOCK_STREAM;
> #endif
> }
> }
>
> And this has me puzzled: SCTP is predominately a SOCK_SEQPACKET, isn't it? 
> (The whole point of using it and not TCP as a transport is it preserves 
> record boundaries, supports out-of-order delivery and message interleaving, 
> etc.)
>
> At least, that's how it registers itself as a protocol in Linux 3.12 in 
> net/sctp/protocol.c ...
>
> Apologies if there's a better mailing list for iWARP specific questions. I'm 
> looking at a lot of this stuff for the first time and having to ramp up 
> quickly.
>
> Thanks,
>
> -Philip
>
>
> ___
> 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] OMPI developer's meeting today

2013-12-12 Thread Ralph Castain

Sorry for delay - we just realized we hadn't addressed this yet.

Plan is to still start at 9am as planned. Hope that is okay.



On Thu, Dec 12, 2013 at 9:52 AM, Ralph Castain  wrote:

> No changes yet, Josh - I'm the only one here :-(
>
> We can revisit the time when the others arrive later today
>
>
>
> On Thu, Dec 12, 2013 at 9:51 AM, Josh Hursey wrote:
>
>> I think we had C/R slated for Friday morning - is that still correct?
>>
>> I have a meeting at 10 that just popped up, so I can only attend for an
>> hour if we start at 9. I just wanted to confirm that that was the current
>> plan or if had been modified.
>>
>> -- Josh
>>
>>
>>
>> On Thu, Dec 12, 2013 at 6:53 AM, Jeff Squyres (jsquyres) <
>> jsquy...@cisco.com> wrote:
>>
>>> For those of you here in Chicago and not coming to the MPI Forum meeting
>>> this morning, feel free to head over to the Cisco facility any time after
>>> 8am US Central time.  Here's the wiki page with the address:
>>>
>>> https://svn.open-mpi.org/trac/ompi/wiki/Dec13Meeting
>>>
>>> We're in the conference room named "Field Museum"; it's been reserved
>>> for the entire day.  Please check with the Cisco Lobby Ambassador upon
>>> arrival; you should be allowed to go to the conference room without being
>>> escorted.  Your wifi access starts this morning, too.
>>>
>>> Those of us at the Forum will go to the Cisco facility when the Forum
>>> meeting ends.  The Forum is scheduled to end at noon; some of us may come
>>> over earlier.  Note that the Forum meeting is downtown and the Cisco
>>> facility is out by O'Hare -- it will take some time to get from one to the
>>> other.
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Joshua Hursey
>> Assistant Professor of Computer Science
>> University of Wisconsin-La Crosse
>> http://cs.uwlax.edu/~jjhursey
>>
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>
>

Re: [OMPI devel] Test suite of openMPI 1.7.3 fails

2013-12-12 Thread Philipp Thomas

* Jeff Squyres (jsquyres) (jsquy...@cisco.com) [20131211 21:01]:

> Can you send the opal_config.h file from your build tree?
> 
> This will help us look into what's going on.

Attached.

Note that it doesn't seem to be dependent on the build architecture as it
fails at the same spot for all Archs that openSUSE supports (i586, x86-64,
armv6l, armv7l ppc, ppc64).

Philipp
/* opal/include/opal_config.h.  Generated from opal_config.h.in by configure.  */
/* opal/include/opal_config.h.in.  Generated from configure.ac by autoheader.  */

/* -*- c -*-
 *
 * Copyright (c) 2004-2005 The Trustees of Indiana University.
 * All rights reserved.
 * Copyright (c) 2004-2005 The Trustees of the University of Tennessee.
 * All rights reserved.
 * Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
 * University of Stuttgart.  All rights reserved.
 * Copyright (c) 2004-2005 The Regents of the University of California.
 * All rights reserved.
 * $COPYRIGHT$
 *
 * Additional copyrights may follow
 *
 * $HEADER$
 *
 * Function: - OS, CPU and compiler dependent configuration
 */

#ifndef OPAL_CONFIG_H
#define OPAL_CONFIG_H

#include "opal_config_top.h"



/* Define if building universal (internal helper macro) */
/* #undef AC_APPLE_UNIVERSAL_BUILD */

/* enable openib BTL failover */
#define BTL_OPENIB_FAILOVER_ENABLED 0

/* Whether the openib BTL malloc hooks are enabled */
#define BTL_OPENIB_MALLOC_HOOKS_ENABLED 1

/* Whether we have IBV_EVENT_GID_CHANGE or not */
#define BTL_USNIC_HAVE_IBV_EVENT_GID_CHANGE 0

/* Whether we have IBV_NODE_USNIC / IBV_TRANSPORT_USNIC or not */
#define BTL_USNIC_HAVE_IBV_USNIC 0

/* Define to 1 if you have the  header file. */
#define HAVE_AIO_H 1

/* Define to 1 if you have the  header file. */
#define HAVE_ALLOCA_H 1

/* Define to 1 if you have the  header file. */
/* #undef HAVE_ALPS_APINFO_H */

/* Define to 1 if you have the  header file. */
#define HAVE_ARPA_INET_H 1

/* Define to 1 if you have the `asprintf' function. */
#define HAVE_ASPRINTF 1

/* Define to 1 if you have the `backtrace' function. */
#define HAVE_BACKTRACE 1

/* Define to 1 if the system has the type `CACHE_DESCRIPTOR'. */
/* #undef HAVE_CACHE_DESCRIPTOR */

/* Define to 1 if the system has the type `CACHE_RELATIONSHIP'. */
/* #undef HAVE_CACHE_RELATIONSHIP */

/* Define to 1 if you have the  header file. */
/* #undef HAVE_CATAMOUNT_CNOS_MPI_OS_H */

/* Define to 1 if you have the  header file. */
/* #undef HAVE_CATAMOUNT_DCLOCK_H */

/* Define to 1 if you have the `ceil' function. */
#define HAVE_CEIL 1

/* Define to 1 if you have the `clz' function. */
/* #undef HAVE_CLZ */

/* Define to 1 if you have the `clzl' function. */
/* #undef HAVE_CLZL */

/* Define to 1 if you have the  header file. */
/* #undef HAVE_CNOS_MPI_OS_H */

/* Define to 1 if you have the  header file. */
#define HAVE_COMPLEX_H 1

/* Define to 1 if you have the `cpuset_setaffinity' function. */
/* #undef HAVE_CPUSET_SETAFFINITY */

/* Define to 1 if you have the  header file. */
/* #undef HAVE_CRT_EXTERNS_H */

/* Define to 1 if you have the `dbm_open' function. */
/* #undef HAVE_DBM_OPEN */

/* Define to 1 if you have the `dbopen' function. */
/* #undef HAVE_DBOPEN */

/* Define to 1 if you have the  header file. */
/* #undef HAVE_DB_H */

/* Define to 1 if you have the declaration of `AF_INET6', and to 0 if you
   don't. */
#define HAVE_DECL_AF_INET6 1

/* Define to 1 if you have the declaration of `AF_UNSPEC', and to 0 if you
   don't. */
#define HAVE_DECL_AF_UNSPEC 1

/* Define to 1 if you have the declaration of `CTL_HW', and to 0 if you don't.
   */
#define HAVE_DECL_CTL_HW 0

/* Define to 1 if you have the declaration of `fabsf', and to 0 if you don't.
   */
#define HAVE_DECL_FABSF 1

/* Define to 1 if you have the declaration of `HW_NCPU', and to 0 if you
   don't. */
#define HAVE_DECL_HW_NCPU 0

/* Define to 1 if you have the declaration of `HZ', and to 0 if you don't. */
#define HAVE_DECL_HZ 1

/* Define to 1 if you have the declaration of `IBV_ACCESS_SO', and to 0 if you
   don't. */
/* #undef HAVE_DECL_IBV_ACCESS_SO */

/* Define to 1 if you have the declaration of `IBV_EVENT_CLIENT_REREGISTER',
   and to 0 if you don't. */
/* #undef HAVE_DECL_IBV_EVENT_CLIENT_REREGISTER */

/* Define to 1 if you have the declaration of `IBV_LINK_LAYER_ETHERNET', and
   to 0 if you don't. */
/* #undef HAVE_DECL_IBV_LINK_LAYER_ETHERNET */

/* Define to 1 if you have the declaration of
   `IBV_M_WR_CALC_RDMA_WRITE_WITH_IMM', and to 0 if you don't. */
/* #undef HAVE_DECL_IBV_M_WR_CALC_RDMA_WRITE_WITH_IMM */

/* Define to 1 if you have the declaration of `PCI_LOOKUP_NO_NUMBERS', and to
   0 if you don't. */
/* #undef HAVE_DECL_PCI_LOOKUP_NO_NUMBERS */

/* Define to 1 if you have the declaration of `PF_INET6', and to 0 if you
   don't. */
#define HAVE_DECL_PF_INET6 1

/* Define to 1 if you have the declaration of `PF_UNSPEC', and to 0 if you

Re: [OMPI devel] OMPI developer's meeting today

2013-12-12 Thread Ralph Castain

No changes yet, Josh - I'm the only one here :-(

We can revisit the time when the others arrive later today



On Thu, Dec 12, 2013 at 9:51 AM, Josh Hursey  wrote:

> I think we had C/R slated for Friday morning - is that still correct?
>
> I have a meeting at 10 that just popped up, so I can only attend for an
> hour if we start at 9. I just wanted to confirm that that was the current
> plan or if had been modified.
>
> -- Josh
>
>
>
> On Thu, Dec 12, 2013 at 6:53 AM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
>
>> For those of you here in Chicago and not coming to the MPI Forum meeting
>> this morning, feel free to head over to the Cisco facility any time after
>> 8am US Central time.  Here's the wiki page with the address:
>>
>> https://svn.open-mpi.org/trac/ompi/wiki/Dec13Meeting
>>
>> We're in the conference room named "Field Museum"; it's been reserved for
>> the entire day.  Please check with the Cisco Lobby Ambassador upon arrival;
>> you should be allowed to go to the conference room without being escorted.
>>  Your wifi access starts this morning, too.
>>
>> Those of us at the Forum will go to the Cisco facility when the Forum
>> meeting ends.  The Forum is scheduled to end at noon; some of us may come
>> over earlier.  Note that the Forum meeting is downtown and the Cisco
>> facility is out by O'Hare -- it will take some time to get from one to the
>> other.
>>
>> --
>> 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
>>
>
>
>
> --
> Joshua Hursey
> Assistant Professor of Computer Science
> University of Wisconsin-La Crosse
> http://cs.uwlax.edu/~jjhursey
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

Re: [OMPI devel] OMPI developer's meeting today

2013-12-12 Thread Josh Hursey

I think we had C/R slated for Friday morning - is that still correct?

I have a meeting at 10 that just popped up, so I can only attend for an
hour if we start at 9. I just wanted to confirm that that was the current
plan or if had been modified.

-- Josh



On Thu, Dec 12, 2013 at 6:53 AM, Jeff Squyres (jsquyres)  wrote:

> For those of you here in Chicago and not coming to the MPI Forum meeting
> this morning, feel free to head over to the Cisco facility any time after
> 8am US Central time.  Here's the wiki page with the address:
>
> https://svn.open-mpi.org/trac/ompi/wiki/Dec13Meeting
>
> We're in the conference room named "Field Museum"; it's been reserved for
> the entire day.  Please check with the Cisco Lobby Ambassador upon arrival;
> you should be allowed to go to the conference room without being escorted.
>  Your wifi access starts this morning, too.
>
> Those of us at the Forum will go to the Cisco facility when the Forum
> meeting ends.  The Forum is scheduled to end at noon; some of us may come
> over earlier.  Note that the Forum meeting is downtown and the Cisco
> facility is out by O'Hare -- it will take some time to get from one to the
> other.
>
> --
> 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
>



-- 
Joshua Hursey
Assistant Professor of Computer Science
University of Wisconsin-La Crosse
http://cs.uwlax.edu/~jjhursey

Re: [OMPI devel] iWARP development

2013-12-12 Thread Ralph Castain

Be aware that we removed SCTP from the 1.7 release series because of its
unknown state of repair - I don't believe anyone has tested it in quite
some time, and nobody has been maintaining it so far as we know. Not saying
it won't work - just saying that I don't think we know :-/



On Wed, Dec 11, 2013 at 6:07 PM, Jeff Squyres (jsquyres)  wrote:

> On Dec 11, 2013, at 5:33 PM, "Prindeville, Philip" <
> philip.prindevi...@hp.com> wrote:
>
> > I was wondering what the current state of iWARP development is.
>
> Open MPI's iWARP support is part of the "openib" BTL (so named because
> OpenFabrics used to be known as OpenIB, before iWARP joined, and we never
> changed the name of our plugin after OFA became OFA).
>
> > There are some features we’re interested in, and from what I can tell
> the iWARP RFCs/Internet Drafts haven’t caught up to related developments.
>
> As George mentioned, we deleted the SCTP plugin from the 1.7 release
> branch -- but that's a standalone SCTP plugin, which is not what I think
> you're asking about it.
>
> > Part of our interest is in using SCTP as the LLP for iWARP, and updating
> that adaptation to the latest SCTP work.
>
> Gotcha.
>
> > For instance:
> >
> > RFC 6458 – SCTP authentication
> > RFC 6458 – SCTP out-of-order delivery
> > RFC 6458 – SCTP association end-point address changes
> > RFC 6458 – SCTP Receive Information
> > RFC 6458 – SCTP partially reliable delivery
> > RFC 6458 – SCTP key management
> > RFC 5061 – SCTP Dynamic address reconfiguration (useful for hot NIC
> swaps in a high availability environment)
> >
> > We’d also like to see load-sharing in multipath environments, and
> sender-side traffic shaping support.
>
> Sounds nifty.
>
> > From what I can tell, the iWARP SCTP work that’s been done predates
> RFC-6458, and hence I’m assuming it’s aligned to RFC-5043.
>
> Sure...?
>
> > Other questions I have:
> >
> > Has this code been tested extensively on non-x86 platforms?  What about
> IA64, PPC64, ARM7, or MIPS 7K?
>
> Doubtful.  The openib BTL is known to work with IB and iWARP on a variety
> of x86 platforms.  I have no idea, and would kinda doubt, if it has been
> tested on any of the other platforms you've specified.
>
> > Is anyone doing any code to port SolarFlare OpenOnload stack to support
> Open MPI’s iWARP?
>
> Nope.  SF has told me/others that they're happy just doing their onload
> TCP through OMPI -- they don't see the need to do their own OO plugin (but
> don't take my word for it; I certainly cannot speak for them -- feel free
> to ask them yourself).
>
> > And a minor note… Just looking at the 1.7.3 tarball and grepping for
> SCTP in it, I find only a few matches, such as this:
> >
> > evutil_getaddrinfo_infer_protocols(struct evutil_addrinfo *hints)
> > {
> > …
> > #ifdef IPPROTO_SCTP
> > else if (hints->ai_protocol ==
> IPPROTO_SCTP)
> > hints->ai_socktype =
> SOCK_STREAM;
> > #endif
> > }
> > }
> >
> > And this has me puzzled: SCTP is predominately a SOCK_SEQPACKET, isn’t
> it? (The whole point of using it and not TCP as a transport is it preserves
> record boundaries, supports out-of-order delivery and message interleaving,
> etc.)
> >
> > At least, that’s how it registers itself as a protocol in Linux 3.12 in
> net/sctp/protocol.c …
> >
> > Apologies if there’s a better mailing list for iWARP specific questions.
> I’m looking at a lot of this stuff for the first time and having to ramp up
> quickly.
> >
> > Thanks,
> >
> > -Philip
> >
> >
> > ___
> > 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
>

[OMPI devel] OMPI developer's meeting today

2013-12-12 Thread Jeff Squyres (jsquyres)

For those of you here in Chicago and not coming to the MPI Forum meeting this 
morning, feel free to head over to the Cisco facility any time after 8am US 
Central time.  Here's the wiki page with the address:

https://svn.open-mpi.org/trac/ompi/wiki/Dec13Meeting

We're in the conference room named "Field Museum"; it's been reserved for the 
entire day.  Please check with the Cisco Lobby Ambassador upon arrival; you 
should be allowed to go to the conference room without being escorted.  Your 
wifi access starts this morning, too.

Those of us at the Forum will go to the Cisco facility when the Forum meeting 
ends.  The Forum is scheduled to end at noon; some of us may come over earlier. 
 Note that the Forum meeting is downtown and the Cisco facility is out by 
O'Hare -- it will take some time to get from one to the other.

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

Re: [OMPI devel] iWARP development

Re: [OMPI devel] iWARP development

Re: [OMPI devel] iWARP development

Re: [OMPI devel] OMPI developer's meeting today

Re: [OMPI devel] Test suite of openMPI 1.7.3 fails

Re: [OMPI devel] OMPI developer's meeting today

Re: [OMPI devel] OMPI developer's meeting today

Re: [OMPI devel] iWARP development

[OMPI devel] OMPI developer's meeting today

9 matches

Site Navigation

Mail list logo

Footer information