On Wed, Mar 18, 2020 at 12:39:44PM +0200, Max Gurtovoy wrote: > > On 3/18/2020 12:29 PM, Leon Romanovsky wrote: > > On Wed, Mar 18, 2020 at 11:46:19AM +0200, Max Gurtovoy wrote: > > > On 3/18/2020 8:47 AM, Leon Romanovsky wrote: > > > > On Tue, Mar 17, 2020 at 06:37:57PM +0200, Max Gurtovoy wrote: > > > > > On 3/17/2020 3:55 PM, Leon Romanovsky wrote: > > > > > > On Tue, Mar 17, 2020 at 03:40:26PM +0200, Max Gurtovoy 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). > > > > > > > > > > > > > > Signed-off-by: Max Gurtovoy <maxg@xxxxxxxxxxxx> > > > > > > > --- > > > > > > > drivers/infiniband/core/Makefile | 2 +- > > > > > > > drivers/infiniband/core/srq_set.c | 78 +++++++++++++++++++++++++++++++++++++++ > > > > > > > drivers/infiniband/core/verbs.c | 4 ++ > > > > > > > include/rdma/ib_verbs.h | 5 +++ > > > > > > > include/rdma/srq_set.h | 18 +++++++++ > > > > > > > 5 files changed, 106 insertions(+), 1 deletion(-) > > > > > > > create mode 100644 drivers/infiniband/core/srq_set.c > > > > > > > create mode 100644 include/rdma/srq_set.h > > > > > > > > > > > > > > diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile > > > > > > > index d1b14887..1d3eaec 100644 > > > > > > > --- a/drivers/infiniband/core/Makefile > > > > > > > +++ b/drivers/infiniband/core/Makefile > > > > > > > @@ -12,7 +12,7 @@ ib_core-y := packer.o ud_header.o verbs.o cq.o rw.o sysfs.o \ > > > > > > > roce_gid_mgmt.o mr_pool.o addr.o sa_query.o \ > > > > > > > multicast.o mad.o smi.o agent.o mad_rmpp.o \ > > > > > > > nldev.o restrack.o counters.o ib_core_uverbs.o \ > > > > > > > - trace.o > > > > > > > + trace.o srq_set.o > > > > > > Why did you call it "srq_set.c" and not "srq.c"? > > > > > because it's not a SRQ API but SRQ-set API. > > > > I would say that it is SRQ-pool and not SRQ-set API. > > > If you have some other idea for an API, please share with us. > > > > > > I've created this API in core layer to make the life of the ULPs easier and > > > we can see that it's very easy to add this feature to ULPs and get a big > > > benefit of it. > > No one here said against the feature, but tried to understand the > > rationale behind name *_set and why you decided to use "set" term > > and not "pool", like was done for MR pool. > > Ok. But srq_pool was the name I used 2 years ago and you didn't like this > back then. I don't like it today too, but don't have better name to suggest. Thanks
