On 3/20/2020 7:59 AM, Sagi Grimberg wrote:
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...
Sagi,
It's surprising to me since in my V1 two years ago I sent a pure
nvmet/RDMA implementation and no srq_pool in there.
And you have asked to add a srq_pool in the review.
Also I was asked to add another implementation with this API for another
ULP back then and I didn't have the capacity for it.
Now I've done both NVMf and SRP target implementation with the SRQ pool.
I'm ok with removing/upgrading the pool in a way everyone would be happy.
I'm ok with removing the SRP implementation if it's not needed.
I just want to add this feature to NVMf target 5.7 release.
So please decide on the implementation and I'll send the patches.
-Max.
