Michael Krause wrote:
The proper action is to propose a new MPA specification to the IETF -
it isn't an OFA decision to make. MPA within the IETF was a tough
fight to get into existence. This particular issue was raised and the
outcome from that debate is what is in the 1.0 specification (it is a
standard if I recall not a draft).
It looks to me to be an ID, not an RFC.
Fine to argue here but action and specification work must be brought
up in the IETF RDDP workgroup and likely to be vetted as well by the
TSVWG and Transport AD (both weighed in quite a bit during MPA's
creation).
If the IETF approves a new draft, then OFA can develop the associated
software.
I think that's backwards. Referring to Page 3 of the Internet Standards
Process document:
o These procedures are explicitly aimed at recognizing and adopting
generally-accepted practices. Thus, a candidate specification
must be implemented and tested for correct operation and
interoperability by multiple independent parties and utilized in
increasingly demanding environments, before it can be adopted as
an Internet Standard.
I think this means that it is not only acceptable, but expected that
anything proposed would have a working, interoperable implememtation.
But there may be multiple software stacks to deal with legacy hardware
/ drivers so the problem isn't just fixed by providing a new MPA
specification. People are using iWARP today that is compliant with
today's MPA specification.
That remains true whether or not additional application level
functionality is added to the API as is being proposed. Whether or not
this additional functionality is itself standardized is a separate issue.
Mike
At 06:25 PM 10/23/2007, Kanevsky, Arkady wrote:
This is still a protocol and should be defined by IETF not OFA.
But if we get agreement from all iWARP vendors this will be a good step.
If we can not get agreement on it on reflector lets do
it at SC'07 OFA dev. conference.
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance Inc. phone: 781-768-5395
1601 Trapelo Rd. - Suite 16. Fax: 781-895-1195
Waltham, MA 02451 central phone: 781-768-5300
> -----Original Message-----
> From: Glenn Grundstrom [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 23, 2007 9:02 PM
> To: Sean Hefty; Steve Wise
> Cc: Roland Dreier; [EMAIL PROTECTED];
> OpenFabrics General
> Subject: RE: [ofa-general] [RFP] support for iWARP
> requirement - activeconnect side MUST send first FPDU
>
> > > That is what I've been trying to push. Both MVAPICH2 and
> > OMPI have been
> > > open to adjusting their transports to adhere to this requirement.
> > >
> > > I wouldn't mind implementing something to enforce this in
> > the IWCM or
> > > the iWARP drivers IF there was a clean way to do it. So
> far there
> > > hasn't been a clean way proposed.
> >
> > Why can't either uDAPL or iW CM always do a send from the active to
> > passive side that gets stripped off? From the active side,
> the first
> > send is always posted before any user sends, and if
> necessary, a user
> > send can be queued by software to avoid a QP/CQ overrun. The
> > completion can simply be eaten by software. On the passive
> side, you
> > have a similar process for receiving the data.
>
> This is similar to an option in the NetEffect driver. A zero
> byte RDMA write is sent from the active side and accounted
> for on the passive side. This can be turned on and off by
> compile and module options for compatibility.
>
> I second Sean's question - why can't uDAPL or the iw_cm do this?
>
> >
> > (Yes this adds wire protocol, which requires both sides to support
> > it.)
> >
> > - Sean
> >
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
