Hi.
I was wondering what the current state of iWARP development is. 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. Part of our interest is in
using SCTP as the LLP for iWARP, and updating that adaptation to the latest
SCTP work.
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.
>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.
Other questions I have:
Has this code been tested extensively on non-x86 platforms? What about IA64,
PPC64, ARM7, or MIPS 7K?
Is anyone doing any code to port SolarFlare OpenOnload stack to support Open
MPI's iWARP?
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
