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

[Kanevsky, Arkady]

Since there is feedback from actual device usage
and interoperability issues this is a good feedback to bring to RDDP
with the proposal.

Sure ULPs which were designed with MPA picularity in mind
do work. But there is not reason to restrict iWARP usage.
Thanks,

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: Michael Krause [mailto:krause at cup.hp.com] 
> Sent: Wednesday, October 24, 2007 1:58 PM
> To: Kanevsky, Arkady; Glenn Grundstrom; 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
> 
> 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
>