lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AD59A399-EFC9-4609-AFCB-8F346E60F5CC@oracle.com>
Date:   Mon, 5 Apr 2021 16:11:32 +0000
From:   Santosh Shilimkar <santosh.shilimkar@...cle.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     Christoph Hellwig <hch@....de>, Doug Ledford <dledford@...hat.com>,
        Jason Gunthorpe <jgg@...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>,
        Chuck Lever III <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-cifs@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "linux-rdma@...r.kernel.org" <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>,
        "netdev@...r.kernel.org" <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>,
        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 Apr 5, 2021, at 7:08 AM, Leon Romanovsky <leon@...nel.org> wrote:
> 
> On Mon, Apr 05, 2021 at 03:41:15PM +0200, Christoph Hellwig wrote:
>> On Mon, Apr 05, 2021 at 08:23:54AM +0300, Leon Romanovsky wrote:
>>> From: Leon Romanovsky <leonro@...dia.com>
>>> 
>>>> From Avihai,
>>> 
>>> Relaxed Ordering is a PCIe mechanism that relaxes the strict ordering
>>> imposed on PCI transactions, and thus, can improve performance.
>>> 
>>> Until now, relaxed ordering could be set only by user space applications
>>> for user MRs. The following patch series enables relaxed ordering for the
>>> kernel ULPs as well. Relaxed ordering is an optional capability, and as
>>> such, it is ignored by vendors that don't support it.
>>> 
>>> The following test results show the performance improvement achieved
>>> with relaxed ordering. The test was performed on a NVIDIA A100 in order
>>> to check performance of storage infrastructure over xprtrdma:
>> 
>> Isn't the Nvidia A100 a GPU not actually supported by Linux at all?
>> What does that have to do with storage protocols?
> 
> This system is in use by our storage oriented customer who performed the
> test. He runs drivers/infiniband/* stack from the upstream, simply backported
> to specific kernel version.
> 
> The performance boost is seen in other systems too.
> 
>> 
>> Also if you enable this for basically all kernel ULPs, why not have
>> an opt-out into strict ordering for the cases that need it (if there are
>> any).
> 
> The RO property is optional, it can only improve. In addition, all in-kernel ULPs
> don't need strict ordering. I can be mistaken here and Jason will correct me, it
> is because of two things: ULP doesn't touch data before CQE and DMA API prohibits it.
> 

Sticking to in-kernel ULP’s don’t need strict ordering, why don’t you enable this
for HCA’s which supports it by default instead of patching very ULPs. Some ULPs
in future may forget to specify such flag.

Regards,
Santosh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ