On 4/20/2021 4:09 AM, Benjamin Block wrote:
On Tue, Apr 20, 2021 at 12:24:41PM +0530, Muneendra Kumar M wrote:
Hi Benjamin,
---
drivers/nvme/host/fc.c | 73
+++++++++++++++++++++++++++++++++++++++++-
1 file changed, 72 insertions(+), 1 deletion(-)
Hmm, I wonder why only NVMe-FC? Or is this just for the moment? We also
have the FC transport class for SCSI; I assume this could feed the same
IDs into the LLDs.
At present it supports only for SCSI-FC .
It does? By adding it to the implementation under `drivers/nvme/host/`?
I am confused.
Yeah, this is a little odd.
This history is: we know we need to merge the scsi fc transport and the
nvme fc transport as the two independent things are creating
difficulties and duplications (devloss is an example). But it's a bit of
work to change this as it will move where the objects are in the
topology tree.
As we tried to figure out how to do the interaction with cgroups, we
wanted to support SCSI and nvme. If you look at how this new attribute
sets the vmid, it's somewhat generic - it just sets the fc appid field
on a cgrp id. There's really nothing that says the cgrp is on a block
device that is scsi or is nvme. It should work on devices regardless of
their underlying protocol type. Which then left the question - where to
place such an attribute.
Given this is an "fc service" and as we knew the transport will be
merged eventually we picked to put it under /sys/class/fc point which is
where we expect to root the common transport. This class point happens
to be owned/created by the nvme fc host code for requesting nve-fc
rediscovery events. It is odd that it creates a requirement to load the
nvme-fc transport in order to set values for scsi fc devices, but we
deemed it acceptable. Guess we need to get going on that merged
transport...
-- james
