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: Jens Axboe <axboe@kernel.dk>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	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: Thu, 15 Jul 2010 12:03:24 -0400	[thread overview]
Message-ID: <yq1mxtspwab.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20100715153410.774329000@de.ibm.com> (Christof Schmitt's message of "Thu, 15 Jul 2010 17:34:10 +0200")

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

Christof> While experimenting with the data integrity support in the
Christof> Linux kernel, i found that the block layer integrity code can
Christof> send integrity data segments for a request that do not adhere
Christof> to the queue limits.  The integrity data segment can be larger
Christof> than queue_max_segment_size and the segment does not adhere to
Christof> the queue_segment_boundary.

Correct.  That was a deliberate design decision.

Modern HBAs allow essentially indefinite chaining and our block layer
segmentation controls are to some extent legacy baggage.  I did not want
to put in a set of constraints on the DI scatterlist because I was
afraid it would encourage vendors to actually them.


Christof> It appears to me that the right way would be to apply the same
Christof> restrictions that are in place for data segments also to
Christof> integrity data segments. The patch works for my experiments
Christof> and applies on top of the current Linux tree (2.6.35-rc5).

Who says constraints on the integrity scatterlist are the same as on the
data ditto?  In my experience they are not.  If you must do this, then
the DI constraints should be separate from the data segmentation ones.
But I'm interested in what motivated this change to begin with.

Your change also has repercussions when merging requests and bios.  We'd
need to honor the DI segmentation constraints when merging.  Otherwise
we may end up going beyond the controller limits when mapping the sgl.

-- 
Martin K. Petersen	Oracle Linux Engineering

  parent reply	other threads:[~2010-07-15 16:04 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 ` Martin K. Petersen [this message]
2010-07-15 16:14   ` [patch 0/1] Apply segment size and segment boundary " 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
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=yq1mxtspwab.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