[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YGvwUI022t/rJy5U@unreal>
Date: Tue, 6 Apr 2021 08:23:28 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Bart Van Assche <bvanassche@....org>
Cc: Doug Ledford <dledford@...hat.com>,
Jason Gunthorpe <jgg@...dia.com>,
Christoph Hellwig <hch@....de>,
Avihai Horon <avihaih@...dia.com>,
Adit Ranadive <aditr@...are.com>,
Anna Schumaker <anna.schumaker@...app.com>,
Ariel Elior <aelior@...vell.com>,
Bernard Metzler <bmt@...ich.ibm.com>,
Chuck Lever <chuck.lever@...cle.com>,
"David S. Miller" <davem@...emloft.net>,
Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>,
Devesh Sharma <devesh.sharma@...adcom.com>,
Faisal Latif <faisal.latif@...el.com>,
Jack Wang <jinpu.wang@...os.com>,
Jakub Kicinski <kuba@...nel.org>,
"J. Bruce Fields" <bfields@...ldses.org>,
Jens Axboe <axboe@...com>,
Karsten Graul <kgraul@...ux.ibm.com>,
Keith Busch <kbusch@...nel.org>, Lijun Ou <oulijun@...wei.com>,
linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nfs@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-rdma@...r.kernel.org, linux-s390@...r.kernel.org,
Max Gurtovoy <maxg@...lanox.com>,
Max Gurtovoy <mgurtovoy@...dia.com>,
"Md. Haris Iqbal" <haris.iqbal@...os.com>,
Michael Guralnik <michaelgur@...dia.com>,
Michal Kalderon <mkalderon@...vell.com>,
Mike Marciniszyn <mike.marciniszyn@...nelisnetworks.com>,
Naresh Kumar PBS <nareshkumar.pbs@...adcom.com>,
netdev@...r.kernel.org, Potnuri Bharat Teja <bharat@...lsio.com>,
rds-devel@....oracle.com, Sagi Grimberg <sagi@...mberg.me>,
samba-technical@...ts.samba.org,
Santosh Shilimkar <santosh.shilimkar@...cle.com>,
Selvin Xavier <selvin.xavier@...adcom.com>,
Shiraz Saleem <shiraz.saleem@...el.com>,
Somnath Kotur <somnath.kotur@...adcom.com>,
Sriharsha Basavapatna <sriharsha.basavapatna@...adcom.com>,
Steve French <sfrench@...ba.org>,
Trond Myklebust <trond.myklebust@...merspace.com>,
VMware PV-Drivers <pv-drivers@...are.com>,
Weihang Li <liweihang@...wei.com>,
Yishai Hadas <yishaih@...dia.com>,
Zhu Yanjun <zyjzyj2000@...il.com>
Subject: Re: [PATCH rdma-next 01/10] RDMA: Add access flags to ib_alloc_mr()
and ib_mr_pool_init()
On Mon, Apr 05, 2021 at 08:27:16AM -0700, Bart Van Assche wrote:
> On 4/4/21 10:23 PM, Leon Romanovsky wrote:
> > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> > index bed4cfe50554..59138174affa 100644
> > --- a/include/rdma/ib_verbs.h
> > +++ b/include/rdma/ib_verbs.h
> > @@ -2444,10 +2444,10 @@ struct ib_device_ops {
> > struct ib_udata *udata);
> > int (*dereg_mr)(struct ib_mr *mr, struct ib_udata *udata);
> > struct ib_mr *(*alloc_mr)(struct ib_pd *pd, enum ib_mr_type mr_type,
> > - u32 max_num_sg);
> > + u32 max_num_sg, u32 access);
> > struct ib_mr *(*alloc_mr_integrity)(struct ib_pd *pd,
> > u32 max_num_data_sg,
> > - u32 max_num_meta_sg);
> > + u32 max_num_meta_sg, u32 access);
> > int (*advise_mr)(struct ib_pd *pd,
> > enum ib_uverbs_advise_mr_advice advice, u32 flags,
> > struct ib_sge *sg_list, u32 num_sge,
> > @@ -4142,11 +4142,10 @@ static inline int ib_dereg_mr(struct ib_mr *mr)
> > }
> >
> > struct ib_mr *ib_alloc_mr(struct ib_pd *pd, enum ib_mr_type mr_type,
> > - u32 max_num_sg);
> > + u32 max_num_sg, u32 access);
> >
> > -struct ib_mr *ib_alloc_mr_integrity(struct ib_pd *pd,
> > - u32 max_num_data_sg,
> > - u32 max_num_meta_sg);
> > +struct ib_mr *ib_alloc_mr_integrity(struct ib_pd *pd, u32 max_num_data_sg,
> > + u32 max_num_meta_sg, u32 access);
> >
> > /**
> > * ib_update_fast_reg_key - updates the key portion of the fast_reg MR
> > diff --git a/include/rdma/mr_pool.h b/include/rdma/mr_pool.h
> > index e77123bcb43b..2a0ee791037d 100644
> > --- a/include/rdma/mr_pool.h
> > +++ b/include/rdma/mr_pool.h
> > @@ -11,7 +11,8 @@ struct ib_mr *ib_mr_pool_get(struct ib_qp *qp, struct list_head *list);
> > void ib_mr_pool_put(struct ib_qp *qp, struct list_head *list, struct ib_mr *mr);
> >
> > int ib_mr_pool_init(struct ib_qp *qp, struct list_head *list, int nr,
> > - enum ib_mr_type type, u32 max_num_sg, u32 max_num_meta_sg);
> > + enum ib_mr_type type, u32 max_num_sg, u32 max_num_meta_sg,
> > + u32 access);
> > void ib_mr_pool_destroy(struct ib_qp *qp, struct list_head *list);
> >
> > #endif /* _RDMA_MR_POOL_H */
>
> Does the new 'access' argument only control whether or not PCIe relaxed
> ordering is enabled? It seems wrong to me to make enabling of PCIe
> relaxed ordering configurable. I think this mechanism should be enabled
> unconditionally if the HCA supports it.
The same proposal (enable unconditionally) was raised during
submission preparations and we decided to follow same pattern
as other verbs objects which receive flag parameter.
Thanks
>
> Thanks,
>
> Bart.
Powered by blists - more mailing lists