From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: hch@lst.de
Cc: Jinyoung CHOI <j-young.choi@samsung.com>,
"kbusch@kernel.org" <kbusch@kernel.org>,
"axboe@fb.com" <axboe@fb.com>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"chaitanya.kulkarni@wdc.com" <chaitanya.kulkarni@wdc.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
martin.petersen@oracle.com
Subject: Re: [PATCH 2/2] nvme-pci: fix metadata mapping length
Date: Wed, 12 Apr 2023 21:34:00 -0400 [thread overview]
Message-ID: <yq18rewbmay.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <20230412065736.GB20550@lst.de> (hch@lst.de's message of "Wed, 12 Apr 2023 08:57:36 +0200")
>> Even if the memory allocated for integrity is physically continuous,
>> struct bio_vec is composed separately for each page size.
>> In order not to use the blk_rq_map_integrity_sg(), the length of the
>> DMA mapping should be the total size of integrity payload.
>
> Hmm, looking outside the bio_vec is pretty nasty.
>
> I think the problem here is that bio_integrity_add_page should
> just add to the existing bvec, similar to bio_add_page and friends.
Yep, that seems like a better approach. We should try to merge.
--
Martin K. Petersen Oracle Linux Engineering
prev parent reply other threads:[~2023-04-13 1:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20230412052443epcms2p836b669a12c4e81368bec2cd340656f73@epcms2p8>
2023-04-12 5:24 ` [PATCH 2/2] nvme-pci: fix metadata mapping length Jinyoung CHOI
2023-04-12 6:57 ` hch
2023-04-12 7:12 ` Jinyoung CHOI
2023-04-12 11:49 ` (2) " hch
2023-04-13 1:37 ` Martin K. Petersen
2023-04-13 2:19 ` Jinyoung CHOI
2023-04-13 2:26 ` (2) " Martin K. Petersen
2023-04-13 1:34 ` Martin K. Petersen [this message]
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=yq18rewbmay.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=axboe@fb.com \
--cc=chaitanya.kulkarni@wdc.com \
--cc=hch@lst.de \
--cc=j-young.choi@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--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 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.