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

[Hefty, Sean]

>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?

The number of callbacks is bound by the number of processes.  The number of queued REQs can be arbitrarily large.

Handling a REJ really isn't an issue.  The easiest thing to do is just drop it and let the next downcall fail in the CM when it checks the state.  You have to be able to do this anyway, since the REQ may have already been reported to the user.

>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.

I don't understand the serialization concern.  A user could have any number of GetRequests() queued in the kernel waiting for new connections.

>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.

I view this as a problem with the CM implementation.  There's no reason for a 'dropped' REQ to go through timewait or any garbage collection.

This patch is for error handling.  If the user provides a large enough backlog of requests, or the requests come in slowly enough this will never get hit.

- Sean