[ewg] Re: [ofw] SC'09 BOF - Meeting notes

[Dhabaleswar Panda]

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-bounces at lists.openfabrics.org
> >> [mailto:ewg-bounces at lists.openfabrics.org] On Behalf Of Roland Dreier
> >> Sent: Thursday, November 19, 2009 9:35 PM
> >> To: Richard Frank
> >> Cc: ofw at 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 at lists.openfabrics.org
> >> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
> >> _______________________________________________
> >> ewg mailing list
> >> ewg at lists.openfabrics.org
> >> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
> >>
> >
> >
> _______________________________________________
> ewg mailing list
> ewg at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
>