From: Logan Gunthorpe <logang@deltatee.com> To: Jason Gunthorpe <jgg@nvidia.com> Cc: Matthew Wilcox <willy@infradead.org>, linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>, Joao Martins <joao.m.martins@oracle.com>, John Hubbard <jhubbard@nvidia.com>, Ming Lei <ming.lei@redhat.com>, linux-block@vger.kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, linux-rdma@vger.kernel.org, dri-devel@lists.freedesktop.org, nvdimm@lists.linux.dev Subject: Re: Phyr Starter Date: Tue, 11 Jan 2022 16:08:35 -0700 [thread overview] Message-ID: <5c3dd9bd-abda-6c9b-8257-182f84f8f842@deltatee.com> (raw) In-Reply-To: <20220111230224.GT2328285@nvidia.com> On 2022-01-11 4:02 p.m., Jason Gunthorpe wrote: > On Tue, Jan 11, 2022 at 03:57:07PM -0700, Logan Gunthorpe wrote: >> >> >> On 2022-01-11 3:53 p.m., Jason Gunthorpe wrote: >>> I just want to share the whole API that will have to exist to >>> reasonably support this flexible array of intervals data structure.. >> >> Is that really worth it? I feel like type safety justifies replicating a >> bit of iteration and allocation infrastructure. Then there's no silly >> mistakes of thinking one array is one thing when it is not. > > If it is a 'a bit' then sure, but I suspect doing a good job here will > be a lot of code here. > > Look at how big scatterlist is, for instance. Yeah, but scatterlist has a ton of cruft; numerous ways to allocate, multiple iterators, developers using it in different ways, etc, etc. It's a big mess. bvec.h is much smaller (though includes stuff that wouldn't necessarily be appropriate here). Also some things apply to one but not the other. eg: a memcpy to/from function might make sense for a phy_range but makes no sense for a dma_range. > Maybe we could have a generic 64 bit interval arry and then two type > wrappers that do dma and physaddr casting? IDK. > > Not sure type safety of DMA vs CPU address is critical? I would argue it is. A DMA address is not a CPU address and should not be treated the same. Logan
WARNING: multiple messages have this Message-ID (diff)
From: Logan Gunthorpe <logang@deltatee.com> To: Jason Gunthorpe <jgg@nvidia.com> Cc: nvdimm@lists.linux.dev, linux-rdma@vger.kernel.org, John Hubbard <jhubbard@nvidia.com>, linux-kernel@vger.kernel.org, Matthew Wilcox <willy@infradead.org>, Ming Lei <ming.lei@redhat.com>, linux-block@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org, netdev@vger.kernel.org, Joao Martins <joao.m.martins@oracle.com>, Christoph Hellwig <hch@lst.de> Subject: Re: Phyr Starter Date: Tue, 11 Jan 2022 16:08:35 -0700 [thread overview] Message-ID: <5c3dd9bd-abda-6c9b-8257-182f84f8f842@deltatee.com> (raw) In-Reply-To: <20220111230224.GT2328285@nvidia.com> On 2022-01-11 4:02 p.m., Jason Gunthorpe wrote: > On Tue, Jan 11, 2022 at 03:57:07PM -0700, Logan Gunthorpe wrote: >> >> >> On 2022-01-11 3:53 p.m., Jason Gunthorpe wrote: >>> I just want to share the whole API that will have to exist to >>> reasonably support this flexible array of intervals data structure.. >> >> Is that really worth it? I feel like type safety justifies replicating a >> bit of iteration and allocation infrastructure. Then there's no silly >> mistakes of thinking one array is one thing when it is not. > > If it is a 'a bit' then sure, but I suspect doing a good job here will > be a lot of code here. > > Look at how big scatterlist is, for instance. Yeah, but scatterlist has a ton of cruft; numerous ways to allocate, multiple iterators, developers using it in different ways, etc, etc. It's a big mess. bvec.h is much smaller (though includes stuff that wouldn't necessarily be appropriate here). Also some things apply to one but not the other. eg: a memcpy to/from function might make sense for a phy_range but makes no sense for a dma_range. > Maybe we could have a generic 64 bit interval arry and then two type > wrappers that do dma and physaddr casting? IDK. > > Not sure type safety of DMA vs CPU address is critical? I would argue it is. A DMA address is not a CPU address and should not be treated the same. Logan
next prev parent reply other threads:[~2022-01-11 23:08 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-10 19:34 Phyr Starter Matthew Wilcox 2022-01-10 19:34 ` Matthew Wilcox 2022-01-11 0:41 ` Jason Gunthorpe 2022-01-11 0:41 ` Jason Gunthorpe 2022-01-11 4:32 ` Matthew Wilcox 2022-01-11 4:32 ` Matthew Wilcox 2022-01-11 15:01 ` Jason Gunthorpe 2022-01-11 15:01 ` Jason Gunthorpe 2022-01-11 18:33 ` Matthew Wilcox 2022-01-11 18:33 ` Matthew Wilcox 2022-01-11 20:21 ` Jason Gunthorpe 2022-01-11 20:21 ` Jason Gunthorpe 2022-01-11 21:25 ` Matthew Wilcox 2022-01-11 21:25 ` Matthew Wilcox 2022-01-11 22:09 ` Logan Gunthorpe 2022-01-11 22:09 ` Logan Gunthorpe 2022-01-11 22:57 ` Jason Gunthorpe 2022-01-11 22:57 ` Jason Gunthorpe 2022-01-11 23:02 ` Logan Gunthorpe 2022-01-11 23:02 ` Logan Gunthorpe 2022-01-11 22:53 ` Jason Gunthorpe 2022-01-11 22:53 ` Jason Gunthorpe 2022-01-11 22:57 ` Logan Gunthorpe 2022-01-11 22:57 ` Logan Gunthorpe 2022-01-11 23:02 ` Jason Gunthorpe 2022-01-11 23:02 ` Jason Gunthorpe 2022-01-11 23:08 ` Logan Gunthorpe [this message] 2022-01-11 23:08 ` Logan Gunthorpe 2022-01-12 18:37 ` Matthew Wilcox 2022-01-12 18:37 ` Matthew Wilcox 2022-01-12 19:08 ` Jason Gunthorpe 2022-01-12 19:08 ` Jason Gunthorpe 2022-01-20 14:03 ` Christoph Hellwig 2022-01-20 17:17 ` Jason Gunthorpe 2022-01-20 17:17 ` Jason Gunthorpe 2022-01-20 14:00 ` Christoph Hellwig 2022-01-11 9:05 ` Daniel Vetter 2022-01-11 9:05 ` Daniel Vetter 2022-01-11 20:26 ` Jason Gunthorpe 2022-01-11 20:26 ` Jason Gunthorpe 2022-01-20 14:09 ` Christoph Hellwig 2022-01-20 13:56 ` Christoph Hellwig 2022-01-20 15:27 ` Keith Busch 2022-01-20 15:27 ` Keith Busch 2022-01-20 15:28 ` Christoph Hellwig 2022-01-20 17:54 ` Robin Murphy 2022-01-11 8:17 ` John Hubbard 2022-01-11 8:17 ` John Hubbard 2022-01-11 14:01 ` Matthew Wilcox 2022-01-11 14:01 ` Matthew Wilcox 2022-01-11 15:02 ` Jason Gunthorpe 2022-01-11 15:02 ` Jason Gunthorpe 2022-01-11 17:31 ` Logan Gunthorpe 2022-01-11 17:31 ` Logan Gunthorpe 2022-01-20 14:12 ` Christoph Hellwig 2022-01-20 21:35 ` John Hubbard 2022-01-20 21:35 ` John Hubbard 2022-01-11 11:40 ` Thomas Zimmermann 2022-01-11 13:56 ` Matthew Wilcox 2022-01-11 13:56 ` Matthew Wilcox 2022-01-11 14:10 ` Thomas Zimmermann 2022-01-20 13:39 ` Christoph Hellwig
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5c3dd9bd-abda-6c9b-8257-182f84f8f842@deltatee.com \ --to=logang@deltatee.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=hch@lst.de \ --cc=jgg@nvidia.com \ --cc=jhubbard@nvidia.com \ --cc=joao.m.martins@oracle.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-rdma@vger.kernel.org \ --cc=ming.lei@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=nvdimm@lists.linux.dev \ --cc=willy@infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.