From: Hannes Reinecke <hare@suse.de>
To: Christoph Hellwig <hch@lst.de>, Max Gurtovoy <mgurtovoy@nvidia.com>
Cc: martin.petersen@oracle.com, sagi@grimberg.me,
linux-nvme@lists.infradead.org, kbusch@kernel.org,
axboe@kernel.dk, linux-block@vger.kernel.org, oren@nvidia.com,
oevron@nvidia.com, israelr@nvidia.com
Subject: Re: [PATCH v1 0/2] Fix failover to non integrity NVMe path
Date: Mon, 24 Apr 2023 08:10:59 +0200 [thread overview]
Message-ID: <5b7ca121-2b85-ddd0-d94b-1739cc5dcbec@suse.de> (raw)
In-Reply-To: <20230424051144.GA9288@lst.de>
On 4/24/23 07:11, Christoph Hellwig wrote:
> On Sun, Apr 23, 2023 at 05:13:28PM +0300, Max Gurtovoy wrote:
>> Hi Christoph/Sagi/Martin,
>>
>> We're encountered a crash while testing failover between NVMeF/RDMA
>> paths to a target that expose a namespace with metadata. The scenario is
>> the following:
>> Configure one initiator/host path on PI offload capable port (e.g ConnectX-5
>> device) and configure second initiator/host path on non PI offload capable
>> port (e.g ConnectX-3).
>
> Hmm. I suspect the right thing to do here is to just fail the second
> connect.
Yeah, I'm slightly unhappy with this whole setup.
If we were just doing DIF I guess the setup could work, but then we have
to disable DIX (as we cannot support integrity data on the non-PI path).
But we would need an additional patch to disable DIX functionality in
those cases.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman
next prev parent reply other threads:[~2023-04-24 6:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-23 14:13 [PATCH v1 0/2] Fix failover to non integrity NVMe path Max Gurtovoy
2023-04-23 14:13 ` [PATCH v1 1/2] block: bio-integrity: export bio_integrity_free func Max Gurtovoy
2023-04-23 16:34 ` kernel test robot
2023-04-23 16:34 ` kernel test robot
2023-04-23 14:13 ` [PATCH v1 2/2] nvme-multipath: fix path failover for integrity ns Max Gurtovoy
2023-04-23 14:22 ` Sagi Grimberg
2023-04-24 5:11 ` [PATCH v1 0/2] Fix failover to non integrity NVMe path Christoph Hellwig
2023-04-24 6:10 ` Hannes Reinecke [this message]
2023-04-24 6:20 ` Christoph Hellwig
2023-04-24 8:53 ` Sagi Grimberg
2023-04-24 9:17 ` Max Gurtovoy
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=5b7ca121-2b85-ddd0-d94b-1739cc5dcbec@suse.de \
--to=hare@suse.de \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=israelr@nvidia.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=mgurtovoy@nvidia.com \
--cc=oevron@nvidia.com \
--cc=oren@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