[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70909c83-5e3a-6cb5-a8c0-6bd2a6688fb4@talpey.com>
Date: Fri, 9 Apr 2021 13:44:23 -0400
From: Tom Talpey <tom@...pey.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: 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>,
linux-rdma <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 4/9/2021 12:40 PM, Jason Gunthorpe wrote:
> On Fri, Apr 09, 2021 at 10:26:21AM -0400, Tom Talpey wrote:
>
>> My belief is that the biggest risk is from situations where completions
>> are batched, and therefore polling is used to detect them without
>> interrupts (which explicitly).
>
> We don't do this in the kernel.
>
> All kernel ULPs only read data after they observe the CQE. We do not
> have "last data polling" and our interrupt model does not support some
> hacky "interrupt means go and use the data" approach.
>
> ULPs have to be designed this way to use the DMA API properly.
Yep. Totally agree.
My concern was about the data being written as relaxed, and the CQE
racing it. I'll reply in the other fork.
> Fencing a DMA before it is completed by the HW will cause IOMMU
> errors.
>
> Userspace is a different story, but that will remain as-is with
> optional relaxed ordering.
>
> Jason
>
Powered by blists - more mailing lists