ULP's can use this API to create/destroy SRQ's with the same characteristics for implementing a logic that aimed to save resources without significant performance penalty (e.g. create SRQ per completion vector and use shared receive buffers for multiple controllers of the ULP).
There is almost no logic in here. Is there a real point in having in the way it is? What is the point of creating a pool, getting all the srqs, manage in the ulp (in an array), putting back, and destroy as a pool? I'd expect to have a refcount for each qp referencing a srq from the pool, and also that the pool would manage the srqs themselves. srqs are long lived resources, unlike mrs which are taken and restored to the pool on a per I/O basis... Its not that I hate it or something, just not clear to me how useful it is to have in this form...