linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: axboe@kernel.dk, hch@lst.de, martin.petersen@oracle.com,
	linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
	linux-scsi@vger.kernel.org, sagi@grimberg.me,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv3 06/10] blk-integrity: simplify counting segments
Date: Tue, 10 Sep 2024 17:41:05 +0200	[thread overview]
Message-ID: <20240910154105.GF23805@lst.de> (raw)
In-Reply-To: <20240904152605.4055570-7-kbusch@meta.com>

On Wed, Sep 04, 2024 at 08:26:01AM -0700, Keith Busch wrote:
> From: Keith Busch <kbusch@kernel.org>
> 
> The segments are already packed to the queue limits when adding them to
> the bio,

I can't really parse this.  I guess this talks about
bio_integrity_add_page trying to append the payload to the last
vector when possible?

> -int blk_rq_count_integrity_sg(struct request_queue *q, struct bio *bio)
> +int blk_rq_count_integrity_segs(struct bio *bio)
>  {
> -	struct bio_vec iv, ivprv = { NULL };
>  	unsigned int segments = 0;
> -	unsigned int seg_size = 0;
> -	struct bvec_iter iter;
> -	int prev = 0;
> -
> -	bio_for_each_integrity_vec(iv, bio, iter) {
>  
> -		if (prev) {
> -			if (!biovec_phys_mergeable(q, &ivprv, &iv))
> -				goto new_segment;
> -			if (seg_size + iv.bv_len > queue_max_segment_size(q))
> -				goto new_segment;
> -
> -			seg_size += iv.bv_len;
> -		} else {
> -new_segment:
> -			segments++;
> -			seg_size = iv.bv_len;

Q: for the data path the caller submitted bio_vecs can be larger
than the max segment size, and given that the metadata API tries
to follow that in general, I'd assume we could also get metadata
segments larger than the segment size in theory, in which case
we'd need to split a bvec into multiple segments, similar to what
bvec_split_segs does.  Do we need similar handling for metadata?
Or are we going to say that metadata must e.g. always be smaller
than PAGE_SIZE as max_segment_sizse must be >= PAGE_SIZE?

> +	for_each_bio(bio)
> +		segments += bio->bi_integrity->bip_vcnt;

If a bio was cloned bip_vcnt isn't the correct value here,
we'll need to use the iter to count the segments.

>  	bio->bi_next = NULL;
> -	nr_integrity_segs = blk_rq_count_integrity_sg(q, bio);
> +	nr_integrity_segs = blk_rq_count_integrity_segs(bio);
>  	bio->bi_next = next;

And instead of playing the magic with the bio chain here, I'd have
a low-level helper to count the bio segments here.

>  
>  	if (req->nr_integrity_segments + nr_integrity_segs >
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 3ed5181c75610..79cc66275f1cd 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -2548,7 +2548,7 @@ static void blk_mq_bio_to_request(struct request *rq, struct bio *bio,
>  	blk_rq_bio_prep(rq, bio, nr_segs);
>  #if defined(CONFIG_BLK_DEV_INTEGRITY)
>  	if (bio->bi_opf & REQ_INTEGRITY)
> -		rq->nr_integrity_segments = blk_rq_count_integrity_sg(rq->q, bio);
> +		rq->nr_integrity_segments = blk_rq_count_integrity_segs(bio);

And here I'm actually pretty sure this is always a single bio and not
a chain either.


  reply	other threads:[~2024-09-10 15:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-04 15:25 [PATCHv3 00/10] block integrity merging and counting Keith Busch
2024-09-04 15:25 ` [PATCHv3 01/10] blk-mq: set the nr_integrity_segments from bio Keith Busch
2024-09-10 15:29   ` Christoph Hellwig
2024-09-04 15:25 ` [PATCHv3 02/10] block: provide helper for nr_integrity_segments Keith Busch
2024-09-10 15:30   ` Christoph Hellwig
2024-09-10 15:39     ` Keith Busch
2024-09-04 15:25 ` [PATCHv3 03/10] scsi: use request helper to get integrity segments Keith Busch
2024-09-10 15:32   ` Christoph Hellwig
2024-09-10 23:02     ` Keith Busch
2024-09-11  8:06       ` Christoph Hellwig
2024-09-04 15:25 ` [PATCHv3 04/10] nvme-rdma: " Keith Busch
2024-09-10 15:32   ` Christoph Hellwig
2024-09-04 15:26 ` [PATCHv3 05/10] block: unexport blk_rq_count_integrity_sg Keith Busch
2024-09-10 15:33   ` Christoph Hellwig
2024-09-04 15:26 ` [PATCHv3 06/10] blk-integrity: simplify counting segments Keith Busch
2024-09-10 15:41   ` Christoph Hellwig [this message]
2024-09-10 16:06     ` Keith Busch
2024-09-11  8:17       ` Christoph Hellwig
2024-09-11 15:28         ` Keith Busch
2024-09-12  7:01           ` Christoph Hellwig
2024-09-04 15:26 ` [PATCHv3 07/10] blk-integrity: simplify mapping sg Keith Busch
2024-09-10 15:43   ` Christoph Hellwig
2024-09-04 15:26 ` [PATCHv3 08/10] blk-integrity: remove inappropriate limit checks Keith Busch
2024-09-10 15:45   ` Christoph Hellwig
2024-09-10 16:21     ` Keith Busch
2024-09-11  8:18       ` Christoph Hellwig
2024-09-11 15:18         ` Keith Busch
2024-09-04 15:26 ` [PATCHv3 09/10] blk-integrity: consider entire bio list for merging Keith Busch
2024-09-10 15:48   ` Christoph Hellwig
2024-09-10 17:19     ` Keith Busch
2024-09-04 15:26 ` [PATCHv3 10/10] blk-merge: properly account for integrity segments Keith Busch
2024-09-06 11:28   ` Anuj Gupta
2024-09-10 15:49   ` 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=20240910154105.GF23805@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=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sagi@grimberg.me \
    /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;
as well as URLs for NNTP newsgroup(s).