mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: grundler@google.com, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: Scatter-gather segment merges by IOMMU?
Date: Fri, 08 Aug 2008 23:58:23 +0200	[thread overview]
Message-ID: <489CC17F.7000208@s5r6.in-berlin.de> (raw)
In-Reply-To: <20080809063159F.fujita.tomonori@lab.ntt.co.jp>

FUJITA Tomonori wrote:
> On Fri, 08 Aug 2008 23:21:28 +0200
> Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> Here is what PPC does:
>> http://lxr.linux.no/linux+v2.6.26/arch/powerpc/kernel/iommu.c#L270
>>
>> It looks at dma_get_max_seg_size(dev); and then merges according to it.
> 
> Yes, IOMMUs were not able to handle this issue but they should now.
> 
> 
>> That's all nice and well, but in my case (FireWire storage protocol 
>> a.k.a. SBP-2, which is basically remote DMA), the max_segment_size of 
>> the PCI device is different from the size limit of the protocol.  We 
>> currently have to deconstruct such merges in the sbp2 drivers again:
>> http://lxr.linux.no/linux+v2.6.26/drivers/firewire/fw-sbp2.c#L1384
>>
>> Either I keep it that way, or I let the protocol driver manipulate the 
>> FireWire controller's dev->dma_parms->max_segment_size (via 
>> dma_set_max_seg_size() of course), which is not entirely correct.
> 
> Why is it not correct? Device drivers can set
> dma_set_max_seg_size(). SCSI does that (see __scsi_alloc_queue).

FireWire is a multi-protocol bus.  SBP-2 is just one of many quite 
different protocols.  SBP-2 targets read or write the initiators memory 
buffers via remote DMA.  These buffer may be exposed as s/g lists to the 
target.  The protocol limits these s/g lists to up to 65535 elements of 
up to 65535 bytes size each.

FireWire controllers on the other hand get their maximum segment size 
set to 65536 by the PCI subsystem.  (All FireWire controllers supported 
by mainline Linux are PCI or PCIe devices.)

In case of the drivers/firewire/ stack, the SBP-2 driver is currently 
the only one which uses dma_map_sg.  In case of the drivers/ieee1394/ 
stack, also the drivers for isochronous protocols, including userspace 
drivers via raw1394, use dma_map_sg.

So if the SBP-2 driver manipulated the controller device's 
max_segment_size, it would influence the DMA mappings of the other 
protocols.  It wouldn't be a big deal; the isochronous mappings could 
only be collapsed to chunks of at most 15 pages instead of 16 pages. 
However, the mapping deconstructing code in the SBP-2 drivers is not a 
big deal either.
-- 
Stefan Richter
-=====-==--- =--- -=---
http://arcgraph.de/sr/

  reply	other threads:[~2008-08-08 22:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08 19:44 Stefan Richter
2008-08-08 20:25 ` Grant Grundler
2008-08-08 21:21   ` Stefan Richter
2008-08-08 21:31     ` FUJITA Tomonori
2008-08-08 21:58       ` Stefan Richter [this message]
2008-08-08 22:17         ` FUJITA Tomonori
2008-08-09 18:20           ` [PATCH] ieee1394: sbp2: enforce s/g segment size limit Stefan Richter
2008-08-09 18:21             ` [PATCH] firewire: fw-sbp2: " Stefan Richter
2008-08-11 19:52               ` Grant Grundler
2008-08-13  9:38                 ` Stefan Richter
2008-08-12 17:04             ` [PATCH] ieee1394: sbp2: " Grant Grundler
2008-08-12 23:44               ` FUJITA Tomonori
2008-08-13 10:19                 ` [PATCH update] " Stefan Richter
2008-08-13 10:20                   ` [PATCH update] firewire: fw-sbp2: " Stefan Richter
2008-08-13 10:27                   ` [PATCH update] ieee1394: sbp2: " Stefan Richter
2008-08-14  0:55                   ` FUJITA Tomonori
2008-08-14  7:12                     ` Stefan Richter
2008-08-14  7:21                       ` FUJITA Tomonori

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=489CC17F.7000208@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=grundler@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@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

all inboxes | Powered by JetHome®