[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210414144907.GD1370958@nvidia.com>
Date: Wed, 14 Apr 2021 11:49:07 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: David Laight <David.Laight@...LAB.COM>
Cc: 'Tom Talpey' <tom@...pey.com>,
Haakon Bugge <haakon.bugge@...cle.com>,
Chuck Lever III <chuck.lever@...cle.com>,
Christoph Hellwig <hch@....de>,
Leon Romanovsky <leon@...nel.org>,
Doug Ledford <dledford@...hat.com>,
Leon Romanovsky <leonro@...dia.com>,
Adit Ranadive <aditr@...are.com>,
Anna Schumaker <anna.schumaker@...app.com>,
Ariel Elior <aelior@...vell.com>,
Avihai Horon <avihaih@...dia.com>,
Bart Van Assche <bvanassche@....org>,
Bernard Metzler <bmt@...ich.ibm.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>,
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>,
CIFS <linux-cifs@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
OFED mailing list <linux-rdma@...r.kernel.org>,
"linux-s390@...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>,
Linux-Net <netdev@...r.kernel.org>,
Potnuri Bharat Teja <bharat@...lsio.com>,
"rds-devel@....oracle.com" <rds-devel@....oracle.com>,
Sagi Grimberg <sagi@...mberg.me>,
"samba-technical@...ts.samba.org" <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 00/10] Enable relaxed ordering for ULPs
On Wed, Apr 14, 2021 at 02:41:52PM +0000, David Laight wrote:
> So whatever driver initialises the target needs to configure whatever
> target-specific register enables the RO transfers themselves.
RDMA in general, and mlx5 in particular, is a layered design:
mlx5_core <- owns the PCI function, should turn on RO at the PCI
function level
mlx5_en <- Commands the chip to use RO for queues used in ethernet
ib_core
ib_uverbs
mlx5_ib <- Commands the chip to use RO for some queues used in
userspace
ib_srp* <- A ULP driver built on RDMA - this patch commands the chip
to use RO on SRP queues
nvme-rdma <- Ditto
ib_iser <- Ditto
rds <- Ditto
So this series is about expanding the set of queues running on mlx5
that have RO turned when the PCI function is already running with RO
enabled.
We want as many queues as possible RO enabled because it brings big
performance wins
Jason
Powered by blists - more mailing lists