All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: 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: Sat, 8 Nov 2025 09:20:08 -0700	[thread overview]
Message-ID: <aQ9tuPo7XLEAIc5i@kbusch-mbp> (raw)
In-Reply-To: <yq1y0ohjk5a.fsf@ca-mkp.ca.oracle.com>

On Fri, Nov 07, 2025 at 10:52:14PM -0500, Martin K. Petersen wrote:
> > +static void blk_crc(struct blk_integrity_iter *iter, void *data,
> > +		    unsigned int len)
> 
> Maybe blk_calculate_checksum() or blk_calculate_guard()? It's a bit
> weird to refer to the IP checksum as a CRC.

Sounds good.
 
> 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.

  reply	other threads:[~2025-11-08 16:20 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 [this message]
2025-11-11 14:14     ` Christoph Hellwig

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=aQ9tuPo7XLEAIc5i@kbusch-mbp \
    --to=kbusch@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --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.