We at OSU have done testing of MVAPICH2 1.4 against the OFED-RDMAoE branch mentioned below. Everything works well. In fact, we made a formal release of MVAPICH2 1.4 with RDMAoE support last month.
Thanks, DK > Is this code new ? We've been evaluating versions of it since before > June/2009. > > We are currently testing with OFED-RDMAoE-1.5-20091116-0620.tgz. > > Our plans are to move from OFED 1.4.2 to OFED 1.5.x in June/2010.. > > It takes us this long to complete internal testing. > > Has anyone else done any evaluation / testing with RDMAoE / RoCEE ? > > > Jeff Squyres wrote: > > FWIW: the dealbreaker for me is that we're already at 1.5rc2. By > > OFED's own rules, new features are not to be allowed. Or you can > > reset the release clock and target Jan/Feb. > > > > Mellanox already has their own OFED distribution -- since there > > appears to be strong desire to get this stuff released ASAP, is there > > an issue with releasing it through Mellanox OFED. Then later release > > it through community OFED in the next go-round? > > > > > > > > On Nov 23, 2009, at 4:18 AM, Liran Liss wrote: > > > >> In the past few months of review, the responsibility for rdmaoe > >> addressing was moved to the rdmacm. > >> So, any future addressing enhancements can be confined to the rdmacm > >> module without breaking existing APIs. > >> > >> RFC 3041 deals with static global IP addresses on the Internet, > >> especially for portable devices. > >> rmdaoe allows using link-local GIDs for applications residing on the > >> same subnet, so I don't see the relevance. > >> Note that for rdmacm apps, the intention is to map the IP addresses that > >> were assigned to the host's interfaces. > >> Please see http://www.t11.org/ftp/t11/pub/fc/study/09-543v0.pdf. > >> > >> Regarding multicast, current switches will flood the traffic just as any > >> other non-IP multicast traffic (e.g., fcoe). > >> Using switches that support multicast pruning for additional ethertypes, > >> you can optimize the traffic and achieve the same link utilization as > >> normal IP multicast. > >> In any case, this is not a correctness issue that prohibits > >> experimentation with rdmaoe multicast on any network today. > >> --Liran > >> > >> > >> -----Original Message----- > >> From: ewg-boun...@lists.openfabrics.org > >> [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Roland Dreier > >> Sent: Thursday, November 19, 2009 9:35 PM > >> To: Richard Frank > >> Cc: o...@lists.openfabrics.org; OpenFabrics EWG > >> Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes > >> > >> > >> > Having lots of testing exposure can help in validating that all the > >> > edge cases are handled.. > >> > >> To some extent -- but there also needs to be some thinking involved to > >> make sure that the interface can actually handle future cases. > >> > >> > Are there a set of cases that you have in mind ? > >> > >> For example -- how is multicast going to interact with IGMP on ethernet > >> switches? How is address resolution going to be done (current patches > >> seem to assume that stateless IPv6 link-local addresses contain the > >> ethernet address, which is not valid if RFC 3041 is used)? etc > >> > >> - R. > >> _______________________________________________ > >> ewg mailing list > >> ewg@lists.openfabrics.org > >> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg > >> _______________________________________________ > >> ewg mailing list > >> ewg@lists.openfabrics.org > >> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg > >> > > > > > _______________________________________________ > ewg mailing list > ewg@lists.openfabrics.org > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg > _______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg