On 4/22/2020 3:07 PM, Max Gurtovoy wrote:
On 4/21/2020 6:17 PM, Christoph Hellwig wrote:
On Fri, Mar 27, 2020 at 08:15:33PM +0300, Max Gurtovoy wrote:
From: Israel Rukshin <israelr@xxxxxxxxxxxx>
Preparation for adding metadata (T10-PI) over fabric support. This will
allow end-to-end protection information passthrough and validation for
NVMe over Fabric.
So actually - for PCIe we enable PI by default. Not sure why RDMA would
be any different? If we have a switch to turn it off we probably want
it work similar (can't be the same due to the lack of connect) for PCIe
as well.
For PCI we use a format command to configure metadata. In fabrics we can
choose doing it in the connect command and we can also choose to have
"protected" controllers and "non-protected" controllers.
I don't think it's all or nothing case, and configuration using nvme-cli
(or other tool) seems reasonable and flexible.
I think you need to change this to "some fabrics".
With FC, we don't do anything in connect. The transport passes
attributes on what it can do for PI support, including: passing through
metadata (no checks); checking of metadata (normal); generation/strip of
metadata on the wire (meaning OS does not have to have a metadata
buffer), and so on. Enablement is just like pci - format the ns, then
match up the attribute with the behavior. There is no such thing as
protected and non-protected controllers. There's either a ns that has
metadata or not. If metadata and the attributes of the transport can't
support it, the ns is inaccessible.
I understand why you are describing it as you are, but I'm a bit
concerned about the creation of things that aren't comprehended in the
standards at all right now (protected vs non-protected controllers).
This affects how multipath configures as well.
-- james
