[ofw] [PATCH 1/4] ib_cm: drop incoming REQs if backlog is full

[Fab Tillier]

>> This isn't quite enforcing a backlog, is it?  Or did you change
>> cm_alloc_id to check a backlog and fail if it's exceeded?  Other than
>> that, the change looks good to me.
>
>  The CEP manager uses a callback model, so it doesn't implement the
> backlog. That's done by the calling code, in this case winverbs, where
> the actual 'queuing' of the REQ is done.
>
> The backlog enforced by winverbs isn't a straight numeric value.  It's
> based on
> whether the user has queued an endpoint object in the kernel by calling
> GetRequest().  If a pending request is not available when the CM REQ is
> received, the REQ is dropped.

The list of pending REQs should be bound by the number of processes.  If a connection request times out you will receive a REJ, and should be able to purge the associated pending REQ from the backlog queue.  Can't you handle the REJ and remove the request from the backlog list?  Or is there no link back from the new ID to the listening ID where such a list would be kept?

I'm concerned here of the serialization this introduces.  At a minimum, I would like to see a single REQ queued, even if it's the last one received.  I would expect the current policy to lengthen connection times under stress.

You're also increasing thrashing by creating/destroying CEPs more frequently, since CEP destruction has to go through the timewait callback.  This could (and should?) be changed though, so that timewait processing isn't overloaded to also do garbage collection.

-Fab