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

[Michael Krause]

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).   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.  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.

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