[ofa-general] Re: setting iWarp IRD and ORD

[Caitlin Bestler]

On Jan 4, 2008 8:16 AM, Steve Wise <swise at opengridcomputing.com> wrote:
> Kanevsky, Arkady wrote:
> > And what happens when RNIC on two sides have a different upper limits?
> > Specifically, if requestor asks for ORD which is bigger than responder
> > can handle?
> > Is it user responsibility to pass ORD request out of bound to responder and
> > if responder can not satisfy it then reject the request?
> > Thanks,
> >
>
> Yes.
>

The key phrase here is that a transport neutral uDAPL application currently
must communicate the *same* IRD/ORD information both between the ULP
peers and from each ULP peer to the transport provider.

There are two benefits to this approach:

     It minimizes the work of the transport provider.

     It optimizes connection setup for those applications that do not need
     to dynamically negotiate the IRD/ORD. This is especially true if the
     out-of-band communication can in fact be a protocol specification
     rather than a dynamic exchange.

There is of course one major drawback to the approach -- it is a complex
requirement that is difficult for application designers to remember.

So this is ultimately a question for application developers. Which is better,
flexibility or uniformity?

If there is a concensus on uniformity, then I believe OFA *could* standardize
an IRD/ORD convention within the private data and that such a convention
would become an industry-wide standard. IT-API already proposed such
an encoding. DAPL never really opposed that encoding, but had previously
decided to avoid creating new wire protocols to ensure interoperability with
non-DAPL applications.

Realistically, OFA applications have virtually no need to interoperate with
non-OFA applications. So a decision could be made to standardize IRD/ORD
setup such that it could be done automatically by the iWARP CM. But such
a decision limits flexibility and steals a few bytes from the available Private
Data. So giving the application developers a chance to express any reservations
should be the next step. That would include anyone who has a scenario where
they need to interoperate with an iWARP application NOT using OFA.