From: "hch@lst.de" <hch@lst.de>
To: Jinyoung CHOI <j-young.choi@samsung.com>
Cc: "axboe@kernel.dk" <axboe@kernel.dk>,
"kbusch@kernel.org" <kbusch@kernel.org>,
"hch@lst.de" <hch@lst.de>, "sagi@grimberg.me" <sagi@grimberg.me>,
"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"johannes.thumshirn@wdc.com" <johannes.thumshirn@wdc.com>,
"kch@nvidia.com" <kch@nvidia.com>,
"willy@infradead.org" <willy@infradead.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 05/14] block: blk-merge: fix to add the number of integrity segments to the request twice
Date: Fri, 12 May 2023 15:51:36 +0200 [thread overview]
Message-ID: <20230512135136.GD32242@lst.de> (raw)
In-Reply-To: <20230510085208epcms2p52a6dec8da80152ec2101f11ce2ea5321@epcms2p5>
The subject looks a bit odd, I think you're trying to say:
"do not add the number of integrity segments to the request twice"
based on the actual patch, is this correct?
> blk_integrity_merge_bio() not only performs conditional tests, but also
> updates the integrity segment information of request.
> It can be called twice when merging the bio into an existing request.
>
> bio_attempt_bio_merge() or blk_mq_sched_try_merge()
> blk_rq_merge_ok()
> blk_integrity_merge_bio() - 1
> bio_attemp_{back|front}_merge()
> ll_{back|front}_merge_fn()
> ll_new_hw_segments()
> blk_integrity_merge_bio() - 2
>
> The part of checking the conditions and the code to update the
> information of the actual request were separated. At this time, the
> ll_back_merge_fn was called by passth-path, so the condition check was
> called by all the separated functions.
>
> And after success in blk_integrity_merge_bio(), the information of the
> request may be wrong if it is impossible to merge due to other
> conditional tests. Thus, it was changed to be called immediately before
> merging the bio's segments.
> +static inline bool blk_integrity_bypass_check(struct request *req,
> + struct bio *bio)
> +{
> + return blk_integrity_rq(req) == 0 && bio_integrity(bio) == NULL;
> +}
No need for the explicit comparisms, this could just be:
return !blk_integrity_rq(req) && !bio_integrity(bio);
and given that it just has two callers I'm not sure the helper is
all that useful to start with.
> +static bool __blk_integrity_mergeable(struct request_queue *q,
> + struct request *req, struct bio *bio)
> +{
> + if (blk_integrity_rq(req) == 0 || bio_integrity(bio) == NULL)
> + return false;
> +
> + if (bio_integrity(req->bio)->bip_flags != bio_integrity(bio)->bip_flags)
> + return false;
> +
> + return true;
> +}
> +
> +bool blk_integrity_mergeable(struct request_queue *q, struct request *req,
> + struct bio *bio)
> +{
> + if (blk_integrity_bypass_check(req, bio))
> + return true;
> +
> + return __blk_integrity_mergeable(q, req, bio);
> +}
Similarly here, I'm not even sure we need all these helpers. I supect
the code would become more readable by dropping these helpers and just
making the checks explicitlẏ
next prev parent reply other threads:[~2023-05-12 13:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230510084407epcms2p123f17696d3c30c749897eeaf2c4de684@epcms2p1>
2023-05-10 8:44 ` [PATCH v2 00/14] Change the integrity configuration method in block Jinyoung CHOI
2023-05-10 8:46 ` [PATCH v2 01/14] block: bio: separation to reuse a part of the function Jinyoung CHOI
2023-05-10 8:48 ` [PATCH v2 02/14] block: bio-integrity: modify bio_integrity_add_page() Jinyoung CHOI
2023-05-12 13:43 ` hch
2023-05-16 12:54 ` Jinyoung CHOI
2023-05-10 8:50 ` [PATCH v2 03/14] block: bio-integrity: cleanup bio_integrity_prep Jinyoung CHOI
2023-05-12 13:45 ` hch
2023-05-10 8:51 ` [PATCH v2 04/14] block: fix not to apply bip information in blk_rq_bio_prep() Jinyoung CHOI
2023-05-12 13:47 ` hch
2023-05-10 8:52 ` [PATCH v2 05/14] block: blk-merge: fix to add the number of integrity segments to the request twice Jinyoung CHOI
2023-05-12 13:51 ` hch [this message]
2023-05-16 13:24 ` Jinyoung CHOI
2023-05-10 8:53 ` [PATCH v2 06/14] block: blk-merge: fix merging two requests in ll_merge_requests_fn Jinyoung CHOI
2023-05-10 8:53 ` [PATCH v2 07/14] block: add helper function to get the number of integrity segments Jinyoung CHOI
2023-05-10 8:56 ` [PATCH v2 08/14] scsi: add scsi_alloc_integrity_sgtables() for integrity process Jinyoung CHOI
2023-05-12 13:52 ` hch
2023-05-17 2:20 ` Jinyoung CHOI
2023-05-10 8:56 ` [PATCH v2 09/14] scsi: change to use blk_rq_nr_integrity_segments() instead of blk_rq_count_integrity_sg() Jinyoung CHOI
2023-05-10 8:58 ` [PATCH v2 10/14] block: blk-integrity: change how to find the number of integrity of bio Jinyoung CHOI
2023-05-10 8:59 ` [PATCH v2 11/14] nvme: rdma: change how to find the number of integrity of request Jinyoung CHOI
2023-05-10 8:59 ` [PATCH v2 12/14] block: add helper function for iteration of bip's bvec Jinyoung CHOI
2023-05-12 13:54 ` hch
2023-05-17 2:35 ` Jinyoung CHOI
2023-05-10 9:00 ` [PATCH v2 13/14] block: blk-integrity: change sg-table configuration method for integrity Jinyoung CHOI
2023-05-10 9:01 ` [PATCH v2 14/14] block: blk-integrity: remove blk_rq_count_integrity_sg() Jinyoung CHOI
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=20230512135136.GD32242@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=j-young.choi@samsung.com \
--cc=jejb@linux.ibm.com \
--cc=johannes.thumshirn@wdc.com \
--cc=kbusch@kernel.org \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
--cc=willy@infradead.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 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.