All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: hch@lst.de, martin.petersen@oracle.com,
	linux-block@vger.kernel.org, axboe@devbig197.nha3.facebook.com,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH] blk-integrity: support bvec straddling block data
Date: Thu, 23 Oct 2025 10:22:01 +0200	[thread overview]
Message-ID: <20251023082201.GA369@lst.de> (raw)
In-Reply-To: <20251022235231.1334134-1-kbusch@meta.com>

On Wed, Oct 22, 2025 at 04:52:31PM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
> 
> A bio segment might have only partial block data that continues into the
> next segment. User the integrity iterator to store the current checksum
> state until we've accumulated a full interval worth of data.

As mentioned in your reply having good tests for this would be really
useful..

>  	void			*data_buf;
>  	sector_t		seed;
>  	unsigned int		data_size;
> +	unsigned int		remaining;
> +	union {
> +		u64		crc64;
> +		__be16		t10pi;
> +	};

Any good reason to keep the t10pi in be format except that is how
the existing t10_pi_csum wrapper works?

> +		if (iter->remaining)
> +			continue;

I find the structure with the remaining continue here a bit confusing.
I guess the code would benefit from being split into an out loop over
the integrity intervals and an inner loop over the potentially smaller
buffers to make this clear.  Even more so with the skip case in the
verify path.

> +		iter->remaining = iter->interval;
> +		iter->t10pi = 0;

And these values basically only matter inside that outer loop, so
I'd just keep them as local variables instead of adding them to
the iter.


  parent reply	other threads:[~2025-10-23  8:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-22 23:52 [PATCH] blk-integrity: support bvec straddling block data Keith Busch
2025-10-23  1:32 ` Keith Busch
2025-10-23  8:22 ` Christoph Hellwig [this message]
2025-10-23 14:39   ` Keith Busch

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=20251023082201.GA369@lst.de \
    --to=hch@lst.de \
    --cc=axboe@devbig197.nha3.facebook.com \
    --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.