From: Christoph Hellwig <hch@lst.de>
To: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>,
Max Gurtovoy <mgurtovoy@nvidia.com>,
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:20:41 +0200 [thread overview]
Message-ID: <20230424062040.GA10281@lst.de> (raw)
In-Reply-To: <5b7ca121-2b85-ddd0-d94b-1739cc5dcbec@suse.de>
On Mon, Apr 24, 2023 at 08:10:59AM +0200, Hannes Reinecke wrote:
> 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.
NVMeoF only supports inline integrity data, the remapping from out of
line integrity data is always done by the HCA for NVMe over RDMA,
and integrity data is not supported without that.
Because of that I can't see how we could sensibly support one path with
integrity offload and one without. And yes, it might make sense to
offer a way to explicitly disable integrity support to allow forming such
a multipath setup.
next prev parent reply other threads:[~2023-04-24 6:20 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
2023-04-24 6:20 ` Christoph Hellwig [this message]
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=20230424062040.GA10281@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=hare@suse.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