Steve Wise wrote:
The rnic might need to reserve resources based on the listen backlog, so
I think the kernel iwarp cma will need this. This is rnic-dependent,
but at least the Ammasso rnic needs to know what the backlog should be.
For OpenIB, we _could_ lock this down to some fixed value on the iwarp
side.
I just committed a patch that removed this from the kernel CMA, but it's easy
enough to put back. I was having issues trying to push the backlog down into
the kernel CMA, versus maintaining it in the uCMA (kernel module to support the
userspace CMA library).
The issues surrounded trying to define something usable for IB that didn't
result in potential system hangs. I considered pushing the backlog down into
the IB CM, but the IB CM doesn't really need a backlog, plus it didn't fix my
system hang issues...
Right now, there's a backlog parameter for userspace that is used to restrict
the number of outstanding connect request events waiting to be retrieved by the
user. (Think of it as sizing a mythical connection event queue maintained in
the kernel.) This works regardless of the underlying transport, but doesn't
pass the backlog information down to lower-level drivers.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
