public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: Jens Axboe <axboe@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: IOMMU and scatterlist limits
Date: Thu, 17 Nov 2005 10:02:32 +0100	[thread overview]
Message-ID: <437C4728.9060205@drzeus.cx> (raw)
In-Reply-To: <20051117085432.GY7787@suse.de>

Jens Axboe wrote:
> On Thu, Nov 17 2005, Pierre Ossman wrote:
>   
>> I'm writing a PCI driver for the first time and I'm trying to wrap my
>> head around the DMA mappings in that world. I've done a ISA driver which
>> uses DMA, but this is a bit more complex and the documentation doesn't
>> explain everything.
>>
>> What I'm particularly confused about is how the IOMMU should be handled
>> with regard to scatterlist limits. My hardware cannot handle
>> scatterlists, only a single DMA address. But from what I understand the
>>     
>
> What kind of hardware can't handle scatter gather?
>
>   

I'd figure most hardware? DMA is handled by writing the start address
into one register and a size into another. Being able to set several
addr/len pairs seems highly advanced to me. :)

>> IOMMU can be very similar to a normal "CPU" MMU. So it should be able to
>> aggregate pages that are non-continuous in physical memory into one
>> single block in bus memory. Now the question is what do I set
>> nr_phys_segments and nr_hw_segments to? Of course the code also needs to
>> handle systems without an IOMMU.
>>     
>
> nr_hw_segments is how many segments your driver will see once dma
> mapping is complete (and the IOMMU has done its tricks), so you want to
> set that to 1 if the hardware can't handle an sg list.
>
>   

And nr_phys_segments? I haven't really grasped the relation between the
two. Is this the number of segments handed to the IOMMU? If so, then I
would need to know how many it can handle (and set it to one if there is
no IOMMU).

> That'll work irregardless of whether there's an IOMMU there or not. Note
> that the mere existence of an IOMMU will _not_ save your performance on
> this hardware, you need one with good virtual merging support to get
> larger transfers.
>
>   

I thought the IOMMU could do the merging through its mapping tables? The
way I understood it, sg support in the device was just to avoid wasting
resources on the IOMMU by using fewer mappings (which would assume the
IOMMU is segment based, not page based).

Rgds
Pierre

  reply	other threads:[~2005-11-17  9:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-17  8:34 IOMMU and scatterlist limits Pierre Ossman
2005-11-17  8:54 ` Jens Axboe
2005-11-17  9:02   ` Pierre Ossman [this message]
2005-11-17  9:13     ` Jens Axboe
2005-11-17  9:27       ` Pierre Ossman
2005-11-17  9:38         ` Jens Axboe
2005-11-17  9:49           ` Pierre Ossman
2005-11-17 12:02             ` Jens Axboe
2005-12-18 22:41           ` Pierre Ossman
2005-12-20 11:10             ` Tejun Heo
2005-12-20 11:36               ` Pierre Ossman
2005-12-20 12:04                 ` Tejun Heo
2005-12-20 12:28                   ` Pierre Ossman

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=437C4728.9060205@drzeus.cx \
    --to=drzeus-list@drzeus.cx \
    --cc=axboe@suse.de \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox