netdev - Re: Phyr Starter

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: <20220112190802.GW2328285@nvidia.com>
Date:   Wed, 12 Jan 2022 15:08:02 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>,
        Joao Martins <joao.m.martins@...cle.com>,
        John Hubbard <jhubbard@...dia.com>,
        Logan Gunthorpe <logang@...tatee.com>,
        Ming Lei <ming.lei@...hat.com>, linux-block@...r.kernel.org,
        netdev@...r.kernel.org, linux-mm@...ck.org,
        linux-rdma@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        nvdimm@...ts.linux.dev
Subject: Re: Phyr Starter

On Wed, Jan 12, 2022 at 06:37:03PM +0000, Matthew Wilcox wrote:
> On Tue, Jan 11, 2022 at 06:53:06PM -0400, Jason Gunthorpe wrote:
> > IOMMU is not common in those cases, it is slow.
> > 
> > So you end up with 16 bytes per entry then another 24 bytes in the
> > entirely redundant scatter list. That is now 40 bytes/page for typical
> > HPC case, and I can't see that being OK.
> 
> Ah, I didn't realise what case you wanted to optimise for.

It is pretty common, even systems with the iommu turned on will run
the kernel drivers with an identity map due to the performance delta..

> Since you want to get to the same destination as I do (a
> 16-byte-per-entry dma_addr+dma_len struct), but need to get there sooner
> than "make all sg users stop using it wrongly", let's introduce a
> (hopefully temporary) "struct dma_range".
> 
> But let's go further than that (which only brings us to 32 bytes per
> range).  For the systems you care about which use an identity mapping,
> and have sizeof(dma_addr_t) == sizeof(phys_addr_t), we can simply
> point the dma_range pointer to the same memory as the phyr.  We just
> have to not free it too early.  That gets us down to 16 bytes per range,
> a saving of 33%.

Yes, that is more or less what I suggested.

I'm not sure I understand your "make all sg users stop using it
wrongly"

I suspect trying to change scatterlist is a tar pit.

Thanks,
Jason