All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Keith Busch <kbusch@meta.com>,
	linux-block@vger.kernel.org, hch@lst.de, axboe@kernel.dk
Subject: Re: [PATCHv3] blk-integrity: support arbitrary buffer alignment
Date: Tue, 11 Nov 2025 15:14:19 +0100	[thread overview]
Message-ID: <20251111141419.GA3378@lst.de> (raw)
In-Reply-To: <aQ9tuPo7XLEAIc5i@kbusch-mbp>

On Sat, Nov 08, 2025 at 09:20:08AM -0700, Keith Busch wrote:
> > To my knowledge, no SCSI controller can handle PI split across segments
> > and the PI tuples are required to be naturally aligned in memory. SCSI
> > controllers probably can't handle split data segments either since the
> > design constraint is one PI segment per protection interval sized data
> > segment.
> 
> There are not many nvme controllers that can handle split pi segments
> either. Anything setting ID_CTRL SGLS.MSDS can do it, but it's a rarely
> advertised capability. For everyone else, metadata buffers have a single
> segment limit.
> 
> As for interval data split across segments, that's totally fine for any
> nvme that supports PI formats. That kind of data was mainly what I was
> initially trying to handle here since that's sufficient to reinstate the
> lower dma_alignment limit. It wasn't much more work to support split pi
> though, unlikely as it is to have hardware capable of it.

I guess we'll just need a flag to distinguish the SCSI vs NVMe
(or HBA vs integrated) semantics here.

      reply	other threads:[~2025-11-11 14:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07 23:23 [PATCHv3] blk-integrity: support arbitrary buffer alignment Keith Busch
2025-11-08  3:52 ` Martin K. Petersen
2025-11-08 16:20   ` Keith Busch
2025-11-11 14:14     ` Christoph Hellwig [this message]

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=20251111141419.GA3378@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=kbusch@kernel.org \
    --cc=kbusch@meta.com \
    --cc=linux-block@vger.kernel.org \
    --cc=martin.petersen@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.