linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Pete Wyckoff <pw@osc.edu>, Erez Zilber <erezz@voltaire.com>,
	Roland Dreier <rolandd@cisco.com>,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 1/3] iscsi iser: remove DMA restrictions
Date: Thu, 14 Feb 2008 12:21:15 -0600	[thread overview]
Message-ID: <47B4869B.9070906@cs.wisc.edu> (raw)
In-Reply-To: <1203012634.3158.5.camel@localhost.localdomain>

James Bottomley wrote:
> On Thu, 2008-02-14 at 11:56 -0600, Mike Christie wrote:
>>> You really don't want to do this.  That signals to the block layer that
>>> we have an iommu, although it's practically the same thing as a 64 bit
>>> DMA mask ... but I'd just leave it to the DMA mask to set this up
>>> correctly.  Anything else is asking for a subtle bug to turn up years
>>> from now when something causes the mask and the limit to be mismatched.
>>>
>> I thought BLK_BOUNCE_ANY just meant "don't bounce anything" (that was 
>> from the blkdev.h comments). 
> 
> It does ... that's why it's used in the IOMMU case ... and why it's
> practically the same as a 64 bit mask.
> 
>> We used it for iscsi_tcp because the network layer can take any type
>> of page and will do the right thing for the hardware it eventually
>> gets sent to.
> 
> Right, to you it means never bounce because net wants to do it instead.
> However, I don't think that's the case for iSER, is it? ... as in, if

I will leave that to Roland and them :)

My only concern with a simple patch to use the ib interface's dma values 
would be, if there is some event that causes us to start using inteface 
ib0 then switch to ib1 (maybe like some sort of route table change if 
that is possible), then we will have to loop over all the scsi devices's 
queues and update the dma values. And if there is IO already queued then 
would we have to possible rebuild those commands if something like the 
dma_mask changed?


> I've got the pathway tracing correct, it just goes to the infiniband
> device and gets mapped there.  If there's a mask mismatch (very
> unlikely, I know) we get a very subtle and hard to trace error.
> 

  reply	other threads:[~2008-02-14 18:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-12 20:52 [PATCH 0/3] iscsi iser limits Pete Wyckoff
2008-02-12 20:54 ` [PATCH 1/3] iscsi iser: remove DMA restrictions Pete Wyckoff
2008-02-12 21:10   ` James Bottomley
2008-02-12 21:46     ` Pete Wyckoff
2008-02-12 21:57       ` James Bottomley
2008-02-13 19:59         ` Pete Wyckoff
2008-02-14 21:10           ` [PATCH 1/3 v2] iscsi iser: remove DMA alignment restriction Pete Wyckoff
2008-05-05 13:19             ` Erez Zilber
2008-04-21 13:51           ` [PATCH 1/3] iscsi iser: remove DMA restrictions Erez Zilber
2008-04-23 13:41             ` [ofa-general] " Erez Zilber
2008-04-23 16:33               ` Mike Christie
2008-04-23 17:16                 ` Mike Christie
2008-04-23 17:43                   ` Mike Christie
2008-02-14 17:56     ` Mike Christie
2008-02-14 18:10       ` James Bottomley
2008-02-14 18:21         ` Mike Christie [this message]
2008-02-14 18:34           ` Mike Christie
2008-02-14 19:04             ` Mike Christie
2008-02-12 20:54 ` [PATCH 2/3] iscsi iser: increase max_sectors Pete Wyckoff
2008-05-05 13:36   ` Erez Zilber
2008-05-05 20:43     ` Roland Dreier
2008-05-05 17:49   ` Mike Christie
2008-05-07 15:53     ` Pete Wyckoff
2008-05-12 12:10       ` Erez Zilber
2008-02-12 20:54 ` [PATCH 3/3] iscsi iser: increase sg_tablesize Pete Wyckoff
2008-03-02 13:56 ` [PATCH 0/3] iscsi iser limits Erez Zilber

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=47B4869B.9070906@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=erezz@voltaire.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pw@osc.edu \
    --cc=rolandd@cisco.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;
as well as URLs for NNTP newsgroup(s).