On 4/23/2020 1:24 AM, James Smart wrote:
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.
it's a bit late for me now so I probably wrote non standard sentence above.
BUT what I meant to say is I would like to give the user an option to
decide whether use E2E protection or not (of course a controller can
control protected and non-protected namespaces :) )
AFAIK, there is no option to format a ns in NVMf (at least for RDMA
there is only 1 lbaf exposed by the target) so i'm not sure how exactly
this will work.
We are doing all or nothing approach in iSER for T10 and I prefer not to
do the same mistake for NVMf as well.
When NVMe/FC will support metadata in Linux we'll be able to adjust the
code and the pi_enable according to HBA cap or any other logic that will
fit.
-- james
