On Wed, 13 Jul 2005, Michael Krause wrote:
At 06:39 AM 7/13/2005, James Lentini wrote:
kDAPL was designed specifically for RDMA networks with lots of features
that allow you to control how the network is used. This is good if you are
writing new code, but means that old code needs substantial porting.
Ideally, applications stay out of such decisions. Middleware's job is to
handle application optimization, etc. so that the end consumer stays as
ignorant as possible thus focused on their application's needs not the
networks. The middleware API - whether DAPL, IT API, RNIC PI, whatever - can
provide the hooks needed to manage the usage from a given endnode's
perspective. But even here, the real network management, what routes are
actually used, the arbitration for QoS, etc. should also be outside of the
middleware's control. It simply manages a set of local resources and allows
the fabric management to do the rest. There is more to this than that but
that is how IB was constructed which is no different in many respects from
how IP works as well.
Let me clarify: kDAPL users can specify exactly how data is transfered
(SEND, RDMA write, RDMA read), completion events are processed, memory
is registered, etc. This is the "network control" I was referring to.
In retrospect, it would be more correct refer to this as "adapter
control".
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
