From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@meta.com>
Cc: linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
hch@lst.de, axboe@kernel.dk, Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCHv4 1/2] block: accumulate memory segment gaps per bio
Date: Fri, 10 Oct 2025 07:34:22 +0200 [thread overview]
Message-ID: <20251010053422.GA16037@lst.de> (raw)
In-Reply-To: <20251007175245.3898972-2-kbusch@meta.com>
On Tue, Oct 07, 2025 at 10:52:44AM -0700, Keith Busch wrote:
> +static inline unsigned int bvec_seg_gap(struct bio_vec *bvprv,
> + struct bio_vec *bv)
> +{
> + return __bvec_gap(bvprv, bv->bv_offset, U32_MAX);
> +}
I find this helper (and the existing __bvec_gap* ones, but I'll send
patches to clean that up in a bit..) very confusing. Just open coding
it in the callers like:
gaps |= (bvprvp->bv_offset + bvprvp->bv_len);
gaps |= bv.bv_offset;
makes the intent clear, and also removes the pointless masking by
U32_MAX.
> + /*
> + * A mask that contains bits set for virtual address gaps between
> + * physical segments. This provides information necessary for dma
> + * optimization opprotunities, like for testing if the segments can be
> + * coalesced against the device's iommu granule.
> + */
> + unsigned int phys_gap;
Any reason this is not a mask like in the bio? Having the representation
and naming match between the bio and request should make the code a bit
easier to understand.
> +
> + /*
> + * The bvec gap bit indicates the lowest set bit in any address offset
> + * between all bi_io_vecs. This field is initialized only after
> + * splitting to the hardware limits. It may be used to consider DMA
> + * optimization when performing that mapping. The value is compared to
> + * a power of two mask where the result depends on any bit set within
> + * the mask, so saving the lowest bit is sufficient to know if any
> + * segment gap collides with the mask.
> + */
This should grow a sentence explaining that the field is only set by
bio_split_io_at, and not valid before as that's very different from the
other bio fields.
> + u8 bi_bvec_gap_bit;
Aren't we normally calling something like this _mask, i.e., something
like:
bi_bvec_page_gap_mask;
next prev parent reply other threads:[~2025-10-10 5:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 17:52 [PATCHv4 0/2] block+nvme: removing virtual boundary mask reliance Keith Busch
2025-10-07 17:52 ` [PATCHv4 1/2] block: accumulate memory segment gaps per bio Keith Busch
2025-10-10 5:34 ` Christoph Hellwig [this message]
2025-10-13 21:33 ` Keith Busch
2025-10-07 17:52 ` [PATCHv4 2/2] nvme: remove virtual boundary for sgl capable devices Keith Busch
2025-10-10 5:34 ` Christoph Hellwig
2025-10-07 18:29 ` [PATCHv4 0/2] block+nvme: removing virtual boundary mask reliance shinichiro.kawasaki
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=20251010053422.GA16037@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 \
/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.