From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: aik@au1.ibm.com, aik@ozlabs.ru, anton@au1.ibm.com,
paulus@samba.org, sparclinux@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David Miller <davem@davemloft.net>
Subject: Re: Generic IOMMU pooled allocator
Date: Mon, 23 Mar 2015 21:11:38 -0400 [thread overview]
Message-ID: <20150324011138.GD21966@oracle.com> (raw)
In-Reply-To: <1427158048.4770.295.camel@kernel.crashing.org>
On (03/24/15 11:47), Benjamin Herrenschmidt wrote:
>
> Yes, pass a function pointer argument that can be NULL or just make it a
> member of the iommu_allocator struct (or whatever you call it) passed to
> the init function and that can be NULL. My point is we don't need a
> separate "ops" structure.
Ok, I'll make this a function pointer to the iommu_tbl_pool_init()
function (tomorrow)
fwiw, the ops struct came out as a result of DaveM input,
http://www.spinics.net/lists/sparclinux/msg13232.html
albeit the original context is now moot.
> Pass it to init and stash it in the table but don't call it
> "iommu_table", let's use a name that conveys better the fact that this
> is purely a DMA space allocator (to be embedded by the arch specific
> iommu table). Something like iommu_alloc_zone or whatever you want to
> call it. I keep finding new names whenever I think of it :-)
please pick a name that you like as this mooshes all the patches,
and I myself really dont care what it gets called (rose? :-)) as long
as fat-fingering-risk is minimized
Regarding the relationship with largepool,
> But that might not be necessary. If indeed we very rarely use the large
> pool, then just make it flush always. My feeling is that it will only
> ever be used at driver init/remove time when allocating things like
> descriptor rings, where the flush overhead dont' matter.
ok, will factor this in tomorrow (assuming DaveM has no objections
to anything proposed here, esp around the function pointer for flushall).
--Sowmini
WARNING: multiple messages have this Message-ID (diff)
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: aik@au1.ibm.com, aik@ozlabs.ru, anton@au1.ibm.com,
paulus@samba.org, sparclinux@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David Miller <davem@davemloft.net>
Subject: Re: Generic IOMMU pooled allocator
Date: Tue, 24 Mar 2015 01:11:38 +0000 [thread overview]
Message-ID: <20150324011138.GD21966@oracle.com> (raw)
In-Reply-To: <1427158048.4770.295.camel@kernel.crashing.org>
On (03/24/15 11:47), Benjamin Herrenschmidt wrote:
>
> Yes, pass a function pointer argument that can be NULL or just make it a
> member of the iommu_allocator struct (or whatever you call it) passed to
> the init function and that can be NULL. My point is we don't need a
> separate "ops" structure.
Ok, I'll make this a function pointer to the iommu_tbl_pool_init()
function (tomorrow)
fwiw, the ops struct came out as a result of DaveM input,
http://www.spinics.net/lists/sparclinux/msg13232.html
albeit the original context is now moot.
> Pass it to init and stash it in the table but don't call it
> "iommu_table", let's use a name that conveys better the fact that this
> is purely a DMA space allocator (to be embedded by the arch specific
> iommu table). Something like iommu_alloc_zone or whatever you want to
> call it. I keep finding new names whenever I think of it :-)
please pick a name that you like as this mooshes all the patches,
and I myself really dont care what it gets called (rose? :-)) as long
as fat-fingering-risk is minimized
Regarding the relationship with largepool,
> But that might not be necessary. If indeed we very rarely use the large
> pool, then just make it flush always. My feeling is that it will only
> ever be used at driver init/remove time when allocating things like
> descriptor rings, where the flush overhead dont' matter.
ok, will factor this in tomorrow (assuming DaveM has no objections
to anything proposed here, esp around the function pointer for flushall).
--Sowmini
next prev parent reply other threads:[~2015-03-24 1:11 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 2:25 Generic IOMMU pooled allocator David Miller
2015-03-19 2:25 ` David Miller
2015-03-19 2:46 ` Benjamin Herrenschmidt
2015-03-19 2:46 ` Benjamin Herrenschmidt
2015-03-19 2:50 ` David Miller
2015-03-19 2:50 ` David Miller
2015-03-19 3:01 ` Benjamin Herrenschmidt
2015-03-19 3:01 ` Benjamin Herrenschmidt
2015-03-19 5:27 ` Alexey Kardashevskiy
2015-03-19 5:27 ` Alexey Kardashevskiy
2015-03-19 13:34 ` Sowmini Varadhan
2015-03-19 13:34 ` Sowmini Varadhan
2015-03-22 19:27 ` Sowmini Varadhan
2015-03-22 19:27 ` Sowmini Varadhan
2015-03-23 16:29 ` David Miller
2015-03-23 16:29 ` David Miller
2015-03-23 16:54 ` Sowmini Varadhan
2015-03-23 16:54 ` Sowmini Varadhan
2015-03-23 19:05 ` David Miller
2015-03-23 19:05 ` David Miller
2015-03-23 19:09 ` Sowmini Varadhan
2015-03-23 19:09 ` Sowmini Varadhan
2015-03-23 22:21 ` Benjamin Herrenschmidt
2015-03-23 22:21 ` Benjamin Herrenschmidt
2015-03-23 23:08 ` Sowmini Varadhan
2015-03-23 23:08 ` Sowmini Varadhan
2015-03-23 23:29 ` chase rayfield
2015-03-24 0:47 ` Benjamin Herrenschmidt
2015-03-24 0:47 ` Benjamin Herrenschmidt
2015-03-24 1:11 ` Sowmini Varadhan [this message]
2015-03-24 1:11 ` Sowmini Varadhan
2015-03-24 1:44 ` David Miller
2015-03-24 1:44 ` David Miller
2015-03-24 1:57 ` Sowmini Varadhan
2015-03-24 1:57 ` Sowmini Varadhan
2015-03-24 2:08 ` Benjamin Herrenschmidt
2015-03-24 2:08 ` Benjamin Herrenschmidt
2015-03-24 2:15 ` David Miller
2015-03-24 2:15 ` David Miller
2015-03-26 0:43 ` cascardo
2015-03-26 0:43 ` cascardo
2015-03-26 0:49 ` Benjamin Herrenschmidt
2015-03-26 0:49 ` Benjamin Herrenschmidt
2015-03-26 10:56 ` Sowmini Varadhan
2015-03-26 10:56 ` Sowmini Varadhan
2015-03-26 22:51 ` David Miller
2015-03-26 23:00 ` David Miller
2015-03-26 23:51 ` Benjamin Herrenschmidt
2015-03-26 23:51 ` Benjamin Herrenschmidt
2015-03-23 22:36 ` Benjamin Herrenschmidt
2015-03-23 22:36 ` Benjamin Herrenschmidt
2015-03-23 23:19 ` Sowmini Varadhan
2015-03-23 23:19 ` Sowmini Varadhan
2015-03-24 0:48 ` Benjamin Herrenschmidt
2015-03-24 0:48 ` Benjamin Herrenschmidt
2015-03-23 22:25 ` Benjamin Herrenschmidt
2015-03-23 22:25 ` Benjamin Herrenschmidt
2015-03-22 19:36 ` Arnd Bergmann
2015-03-22 19:36 ` Arnd Bergmann
2015-03-22 22:02 ` Benjamin Herrenschmidt
2015-03-22 22:02 ` Benjamin Herrenschmidt
2015-03-22 22:07 ` Sowmini Varadhan
2015-03-22 22:07 ` Sowmini Varadhan
2015-03-22 22:22 ` Benjamin Herrenschmidt
2015-03-22 22:22 ` Benjamin Herrenschmidt
2015-03-23 6:04 ` Arnd Bergmann
2015-03-23 6:04 ` Arnd Bergmann
2015-03-23 11:04 ` Benjamin Herrenschmidt
2015-03-23 11:04 ` Benjamin Herrenschmidt
2015-03-23 18:45 ` Arnd Bergmann
2015-03-23 18:45 ` Arnd Bergmann
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=20150324011138.GD21966@oracle.com \
--to=sowmini.varadhan@oracle.com \
--cc=aik@au1.ibm.com \
--cc=aik@ozlabs.ru \
--cc=anton@au1.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=sparclinux@vger.kernel.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: link
Be 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.