[ofa-general] [RFP] support for iWARP requirement - activeconnect side MUST send first FPDU

[Tom Tucker]

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: arkady at netapp.com
>> 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:ggrundstrom at NetEffect.com]
>> > Sent: Tuesday, October 23, 2007 9:02 PM
>> > To: Sean Hefty; Steve Wise
>> > Cc: Roland Dreier; interop-wg at lists.openfabrics.org;
>> > 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
>> > general at lists.openfabrics.org
>> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>> >
>> > To unsubscribe, please visit
>> > http://openib.org/mailman/listinfo/openib-general
>> >
>> _______________________________________________
>> general mailing list
>> general at lists.openfabrics.org
>> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>>
>> To unsubscribe, please visit 
>> http://openib.org/mailman/listinfo/openib-general
>
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general