From: Benjamin Herrenschmidt <benh@au1.ibm.com>
To: Steve Wise <swise@opengridcomputing.com>
Cc: benh@ozlabs.au.ibm.com, Roland Dreier <rdreier@cisco.com>,
linux-kernel@vger.kernel.org,
OpenFabrics General <general@lists.openfabrics.org>,
Benjamin Herrenschmidt <bherren@au1.ibm.com>,
Wen Xiong <wenxiong@us.ibm.com>, Olof Johansson <olof@lixom.net>,
Paul Mackerras <pmac@au1.ibm.com>
Subject: Re: iommu dma mapping alignment requirements
Date: Fri, 21 Dec 2007 08:26:57 +1100 [thread overview]
Message-ID: <1198186017.6779.28.camel@pasglop> (raw)
In-Reply-To: <476AD84E.4000507@opengridcomputing.com>
On Thu, 2007-12-20 at 15:02 -0600, Steve Wise wrote:
> Benjamin Herrenschmidt wrote:
> > Adding A few more people to the discussion. You may well be right and we
> > would have to provide the same alignment, though that sucks a bit as one
> > of the reason we switched to 4K for the IOMMU is that the iommu space
> > available on pSeries is very small and we were running out of it with
> > 64K pages and lots of networking activity.
> >
>
> But smarter NIC drivers can resolve this too, I think, but perhaps
> carving up full pages of mapped buffers instead of just assuming mapping
> is free...
True, but the problem still happenens today, if we switch back to 64K
iommu page size (which should be possible, I need to fix that), we
-will- run out of iommu space on typical workloads and that is not
acceptable.
So we need to find a compromise.
What I might do is something around the lines of: If size >= PAGE_SIZE,
and vaddr (page_address + offset) is PAGE_SIZE aligned, then I enforce
alignment of the resulting mapping.
That should fix your case. Anything requesting smaller than PAGE_SIZE
mappings would lose that alignment but I -think- it should be safe, and
you still always get 4K alignment anyway (+/- your offset) so at least
small alignment restrictions are still enforced (such as cache line
alignment etc...).
I'll send you a test patch later today.
Ben.
next prev parent reply other threads:[~2007-12-20 21:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-20 17:14 iommu dma mapping alignment requirements Steve Wise
2007-12-20 17:29 ` [ofa-general] " Tom Tucker
2007-12-20 18:07 ` Roland Dreier
2007-12-20 19:11 ` Steve Wise
2007-12-20 19:29 ` Steve Wise
2007-12-20 20:21 ` Benjamin Herrenschmidt
2007-12-20 21:22 ` Steve Wise
2007-12-20 20:17 ` Benjamin Herrenschmidt
2007-12-20 21:02 ` Steve Wise
2007-12-20 21:26 ` Benjamin Herrenschmidt [this message]
2007-12-20 22:12 ` Steve Wise
2007-12-20 23:49 ` Benjamin Herrenschmidt
2007-12-21 4:49 ` Steve Wise
2007-12-21 5:38 ` Benjamin Herrenschmidt
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=1198186017.6779.28.camel@pasglop \
--to=benh@au1.ibm.com \
--cc=benh@ozlabs.au.ibm.com \
--cc=bherren@au1.ibm.com \
--cc=general@lists.openfabrics.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=pmac@au1.ibm.com \
--cc=rdreier@cisco.com \
--cc=swise@opengridcomputing.com \
--cc=wenxiong@us.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox