On Thu, Mar 19, 2020 at 10:59:33PM -0700, 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, Why do we need such complexity of referencing to the QPs? This SRQ pool is intended for the kernel users whom we trust and we don't expect that QP will be destroyed before SRQ. Thanks
