[openib-general] RFC userspace CMA

[Tom Tucker]

Ah, I think I understand the confusion. 0 in this case, doesn't mean
"wildcard", it means "assign a port for me". I think you already handle
this in IB... from ib_cm_listen ... 

	spin_lock_irqsave(&cm.lock, flags);
	if (service_id == IB_CM_ASSIGN_SERVICE_ID) {
--->		cm_id->service_id = cpu_to_be64(cm.listen_service_id++);
--->		cm_id->service_mask = __constant_cpu_to_be64(~0ULL);
	} else {
		cm_id->service_id = service_id;
		cm_id->service_mask = service_mask;
	}
	cur_cm_id_priv = cm_insert_listen(cm_id_priv);



On Wed, 2005-10-26 at 11:02 -0700, Sean Hefty wrote: 
> Tom Tucker wrote:
> >>Something that didn't make sense for the kernel rdma_cm running over IB was 
> >>adding a backlog parameter to the listen request.  (The IB CM is callback 
> >>driven, so there's not really a backlog.)  I will probably add this to the 
> >>userspace API.  Does iWarp need a backlog parameter in the kernel?
> > 
> > It is needed by some adapters. For the AMSO1100 it's passed down to the
> > adapter to reserve syn cache entries for incoming connections. 
> 
> There's no problem adding this.  It just that for IB, the user can control the 
> backlog themselves, which gives a little more flexibility.  I suppose we can 
> define it as the maximum number of unacknowledged connection requests that a 
> user can have.  Where acknowledging a connection request is done by accepting or 
> rejecting the connection.  I'll work on adding this after getting the userspace 
> CMA up.
> 
> > Yes it's funky. Basically, the listen in this context is the combination
> > of a 'bind' and a 'listen'. If you specify 0 for a port number on bind,
> > the stack will allocate one for you. 
> 
> I need to think about this more.  I'm not sure how to handle a bind of 0 over 
> IB.  Can you handle this on the bind only, as opposed to listen?
> 
> - Sean