On Wed, 2007-05-09 at 15:01 -0700, Sean Hefty wrote:
> > The reason it is hard or impossible to solve this in the DAPL layer is
> > that any rdma operation on the QP affects the state of that QP and the
> > associate CQs. In addition, if you use an RDMA send to enforce this you
> > impact the other side by consuming a RECV buffer. So its hard if not
> > impossible to do this under the covers without affecting the
> > application's resources.
> I agree that this is hard, but I don't believe that it's impossible.
> > Also, the DAPL specification had a goal to not impose any additional
> > protocol on the wire. If you add this under the covers, then you add
> > such a "protocol" and break interoperability between a connection
> > accessed via DAPL on one end and some other API on the other end.
> IMO, this is a unrealized dream. DAPL does generate wire protocol. For
> example, when running over IB, DAPL's selection of a service ID and CM protocol
> is visible on the wire. A DAPL that establishes connections using the RDMA CM
> will likely have a different wire protocol than a version of DAPL that
> establishes connections talking directly to the IB CM. The two DAPLs will not
> interoperate unless they agree on how they will map to service IDs and, in the
> case of using the RDMA CM, the format of the private data carried in the CM
I wasn't aware of this.
> Even in the case of iWarp, DAPL's selection of a local port number affects the
> data visible on the wire. TO communicate, a remote end point must know how this
> mapping occurs.
You mean the local port on the active side? The remote end point
doesn't need to know this at all...