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: [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
