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 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.