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<mailto:jsquy...@cisco.com>> wrote: On Dec 11, 2013, at 5:33 PM, "Prindeville, Philip" <philip.prindevi...@hp.com<mailto: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<mailto:de...@open-mpi.org> > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com<mailto: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<mailto:de...@open-mpi.org> http://www.open-mpi.org/mailman/listinfo.cgi/devel
