Subject: RE: [Tsvwg] RE: [rdma] Re: RDMA over IP Requirements draft

From: [email-masked]
Date: Mon, 20 May 2002 11:53:28 -0400

Doug,

> There are two points being made where it would appear you agree with
> identifying payloads.  This identification is needed to imply interface
> definitions.  The other point (less important to RDMA, but useful for DDP)
> would be for request structures to comply to a BNF IDL.  At the minimum,
> identifying the payloads would acknowledge when such compliance can be
> expected.

At the moment, I would prefer to do the latter via the former - once the
interface definition is known, that definition (which has to be known to
both sides for the communication to work, independent of whether it's static
or dynamic) contains all the information required to byte-swap payloads.
I would think that it should be the ULP's responsibility to determine
whether to use byte-swapping integrated with DDP and how to configure
that functionality.  I tend to agree with David Robinson that doing any
work to integrate IDL-based byte-swapping with DDP is probably out of scope.

I suspect that payload identification will be a multi-step process based
on the current usage of PPI values - the PPI identifies the ULP, and then
one has to look in the ULP payloads to figure out which data structures
are present.  In any case, for the requirements document, preservation of
transport-specific payload identification information seems like a good
addition, and should be enough to make this sort of IDL-based byte-swapping
possible; the most I could see for the latter sort of functionality is a
"do not prevent" goal, and if in practice that translates into making sure
the SCTP PPI works with DDP, I don't see the point of adding it.  Are there
any other requirements this generates on DDP/RDMA  aside from not breaking
things like the SCTP PPI?

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 20 May 2002 10:09:10 -0700

David,

I agree with your points, but RDMA should introduce few requests structures.
If possible, making these structures compliant to an IDL would minimize a
hardware requirement for those adapters that will also deal with other
protocols.  I would see such a requirement more suitable if this
requirements document was intended for DDP.  As RDMA is driving this effort,
perhaps the most that can be hoped for is a suggestion.

 -Doug

On May 20, 2002 8:53 AM David Black ([email-masked]) wrote:
> > identifying payloads.  This identification is needed to imply
> > interface definitions.  The other point (less important to RDMA, but
> > useful for DDP) would be for request structures to comply to a BNF
> > IDL.  At the minimum, identifying the payloads would acknowledge when
> > such compliance can be expected.
>
> both sides for the communication to work, independent of whether
> it's static or dynamic) contains all the information required to byte-
> swap payloads. I would think that it should be the ULP's responsibility
> to determine whether to use byte-swapping integrated with DDP and how to
> configure that functionality.  I tend to agree with David Robinson that
> doing any work to integrate IDL-based byte-swapping with DDP is probably
> out of scope.
>
> on the current usage of PPI values - the PPI identifies the ULP, and
> then one has to look in the ULP payloads to figure out which data
> structures are present.  In any case, for the requirements document,
> preservation of transport-specific payload identification information
> seems like a good addition, and should be enough to make this sort of
> IDL-based byte-swapping possible; the most I could see for the latter
> sort of functionality is a "do not prevent" goal, and if in practice
> that translates into making sure the SCTP PPI works with DDP, I don't
> see the point of adding it. Are there any other requirements this
> generates on DDP/RDMA  aside from not breaking things like the SCTP PPI?
>
> Thanks,
> --David