public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Christof Schmitt <christof.schmitt@de.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/1] Apply segment size and segment boundary to integrity data
Date: Tue, 03 Aug 2010 00:44:50 -0400	[thread overview]
Message-ID: <yq1vd7s8ful.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20100802110517.GA4556@schmichrtp.mainz.de.ibm.com> (Christof Schmitt's message of "Mon, 2 Aug 2010 13:05:17 +0200")

>>>>> "Christof" == Christof Schmitt <christof.schmitt@de.ibm.com> writes:

Christof> To summarize the limits i see in the zfcp hardware:
Christof> - Maximum size of 4k per segment
Christof> - The segments must not cross page boundaries
Christof> - The number of segments per request is limited

The interesting thing here is that your hw has a limit for the total
number of segments whereas other DIX HBAs have separate limits for data
and integrity scatterlists.


Christof> What would be the preferred approach for handling the
Christof> integrity data limits in the block layer? Introduce new queue
Christof> limits for integrity data, or assume that the limits for
Christof> integrity data are the same as for user data? I can update my
Christof> patch accordingly and include a check for the maximum number
Christof> of segments.

I've been messing with this tonight.  It's not entirely trivial because
of the housekeeping involved, having to accomodate different types of
hardware, having to avoid breaking existing setups, and having to work
with integrity compiled and without.

My first attempt at this got quite messy.  I think I have found a way
but it's bedtime here.  Give me a day or two to get back to you with
something that'll hopefully work for everyone.

-- 
Martin K. Petersen	Oracle Linux Engineering

  reply	other threads:[~2010-08-03  4:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-15 15:34 [patch 0/1] Apply segment size and segment boundary to integrity data Christof Schmitt
2010-07-15 15:34 ` [patch 1/1] block: Apply segment size and boundary limits " Christof Schmitt
2010-07-15 15:53   ` Jens Axboe
2010-07-15 16:03 ` [patch 0/1] Apply segment size and segment boundary " Martin K. Petersen
2010-07-15 16:14   ` Jens Axboe
2010-07-15 16:35     ` Martin K. Petersen
2010-07-15 16:40       ` Jens Axboe
2010-07-16  8:30   ` Christof Schmitt
2010-07-20  4:45     ` Martin K. Petersen
2010-07-20  9:28       ` Christof Schmitt
2010-07-21  4:20         ` Martin K. Petersen
2010-08-02 11:05           ` Christof Schmitt
2010-08-03  4:44             ` Martin K. Petersen [this message]
2010-08-11  8:07               ` Christof Schmitt

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=yq1vd7s8ful.fsf@sermon.lab.mkp.net \
    --to=martin.petersen@oracle.com \
    --cc=axboe@kernel.dk \
    --cc=christof.schmitt@de.ibm.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