[openib-general][PATCH][RFC]: CMA IB implementation

[Caitlin Bestler]

> -----Original Message-----
> From: openib-general-bounces at openib.org 
> [mailto:openib-general-bounces at openib.org] On Behalf Of Guy German
> Sent: Wednesday, September 21, 2005 12:59 AM
> To: Sean Hefty
> Cc: Openib
> Subject: Re: [openib-general][PATCH][RFC]: CMA IB implementation
> 
> Sean Hefty wrote:
> > Guy German wrote:
> >> static void cma_route_handler(u64 req_id, void *context, 
> int rec_num) 
> >> {
> >>     status = ib_at_paths_by_route(&cma_ctx->cma_route, 0,
> >>                       &cma_ctx->cma_path, 1,
> >>                       &cma_ctx->ibat_comp); } int 
> >> ib_cma_connect(struct ib_cma_conn *cma_conn, void **cma_id) {
> >>     status = ib_at_route_by_ip(dst_ip, 0, 0, 0, 
> &cma_ctx->cma_route,
> >>                    &cma_ctx->ibat_comp); };
> > 
> > I still think that it may be better for the user to get the 
> route/path 
> > separately from establishing a connection.  This simplifies the 
> > internal state handling, and I believe maps better to the user 
> > allocating the QP, transitioning it to the INIT state, and 
> pre-posting 
> > receive buffers.  An application may want to change its 
> behavior based 
> > on its path (such as MTU or data rate). Integrating this in 
> with the 
> > connect call requires applications that want to do this to operate 
> > with the lower level connection interfaces.
> 
> The problems I see with asynchronous route/arp model in the 
> generic cm API is that consumers will have to deal with 
> complicated caching (that can be implemented in the at 
> module) and that it is not native to iwarp.
> 
> What do other people think about it ?
> 

Any split in the API needs to allow iWARP providers to
implement the first part as a nop. iWARP is defined on
top of IP transports, and in fact frequently is cleanly
layered over at least the IP layer (full clean separation
from the TCP layer being a bit less common). So the
iWARP implementation may literally have no access to
ARP data.

Ultimately, that is an extreme example of the caching
benefits Guy referenced even for IB providers. 

My question on this remains, what applications would
really use this split? And wouldn't the speciail
requirements of these applications, which I believe
is a subset even of appliations that know they are
using InfiniBand, mean that they would use the IB
specific CM API (with explicit CM MADs)?