From: Max Gurtovoy <mgurtovoy@nvidia.com>
To: Christoph Hellwig <hch@lst.de>, Israel Rukshin <israelr@nvidia.com>
Cc: Linux-nvme <linux-nvme@lists.infradead.org>,
Sagi Grimberg <sagi@grimberg.me>,
Nitzan Carmi <nitzanc@nvidia.com>,
oevron@nvidia.com
Subject: Re: [PATCH] nvme-rdma: Fix T10-PI when SW doesn't generate/verify metadata
Date: Wed, 7 Jun 2023 11:03:25 +0300 [thread overview]
Message-ID: <ec66d848-5246-529a-7050-afca3d1d981f@nvidia.com> (raw)
In-Reply-To: <20230607050855.GA20010@lst.de>
On 07/06/2023 8:08, Christoph Hellwig wrote:
> On Tue, Jun 06, 2023 at 01:51:30PM +0300, Israel Rukshin wrote:
>> When the SW doesn't generate/verify metadata, the SG length is
>> smaller than the transfer length.
>
> What is "the SW"?
better to say the block layer.
>
>> length when there is no metadata SGL. The bug reproduces when
>> setting read_verify/write_generate to 0 at the child multipath
>> device or at the primary device when multipath is disabled. Note
>> that setting those to 0 on the multipath device doesn't have any
>> impact on the I/Os.
>
> And we really need to prevent this from happening per the last
> discussion. Please submit a patch to fail adding a new path to
> a ns_head if the PI settings mismatch.
We're working on it.
I'm not sure what is the intention regarding the support for having
shared namespaces that are not under multipath. There is some comment in
the code that some support will be removed.
Will we allow the same namespace to be exposed twice ? or only the first
one will be exposed in case there is no match in the PI-offload
capabilities ?
but the above doesn't answer what is the behavior we should have if we
change the read_verify/write_generate of the head device ? should it
propagate to the children ?
prev parent reply other threads:[~2023-06-07 8:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 10:51 [PATCH] nvme-rdma: Fix T10-PI when SW doesn't generate/verify metadata Israel Rukshin
2023-06-07 5:08 ` Christoph Hellwig
2023-06-07 8:03 ` Max Gurtovoy [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=ec66d848-5246-529a-7050-afca3d1d981f@nvidia.com \
--to=mgurtovoy@nvidia.com \
--cc=hch@lst.de \
--cc=israelr@nvidia.com \
--cc=linux-nvme@lists.infradead.org \
--cc=nitzanc@nvidia.com \
--cc=oevron@nvidia.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).