2023Q2 status report for NVMe over Fabrics

[pauamma_gundo.com]

In addition to the line edits, could you rewrap this so each sentence is on a single line of its own?

website/content/en/status/report-2023-04-2023-06/nvmf.adoc

5

For consistency with other reports.

14

Is it FibreChannel or Fibre Channel? (Wikipedia thinks the latter.)

18

23–26

I forget: do we still mark up filenames and pathnames? @carlavilla, I think you mentioned that changing?

28

31–32

Use man:nvme[4], and likewise for nvmf and nvd. Also, what's a SIM here?

46

53

62

Add a final newline while here?

[salvadore]

Thanks to @jhb for the report and to @pauamma_gundo.com for the review.

website/content/en/status/report-2023-04-2023-06/nvmf.adoc

23–26

I let @carlavilla reply to this, but if he confirms that we still markup filnames and pathnames, please add the markup.

36

One more man macro here: man:nvmf[4].

45

Please avoid contractions:
s/don't/do not/

62

I am unsure I understand this comment. Why do you recommend a final new line? Do we usually have one?

[jhb]

website/content/en/status/report-2023-04-2023-06/nvmf.adoc

31–32

nvmf(4) doesn't exist since it's not in the tree, so that would be a dead link (and even in the branch I don't yet have a nvmf(4)). Do you still want the markup for a link that will be dead?

In CAM, a peripheral is a driver for a individual storage device like daX for a SCSI disk, adaX for a SATA disk, or ndaX for an NVMe namespace. A SIM is a driver for a storage controller that has a collection of peripheral devices. So for a driver like mpt(4), it uses a SIM as the "glue" between mpt(4) and the rest of CAM. A similar analog for a network driver would be something like 'struct ifnet' which serves as the abstraction that individual NIC drivers use to export logical network interfaces to the network stack. The role of a SIM is described in a bit more detail in cam(4) which gives a general overview of the CAM subsystem. Part of the reason I'm using specific language here is that nvme(4) is an unusual driver in that it can export disks in two different ways: nvd(4) is a NVMe-specific disk device that attaches directly to nvme(4) instances and was imported with the original nvme(4) driver. Later a CAM SIM was added to support NVMe namespaces, and nvme(4) has a tunable to let you choose whether namespaces are exposed as either nvdX devices or ndaX devices. Note that this tunable's default has been changed to default to ndaX for 14.0. nvmf(4) is only going to provide ndaX and does not support nvdX at all. If it weren't for this odd situation with nvme(4) supporting two different modes (which no other storage driver in the tree does BTW), I wouldn't be mentioning this at all. That said, the previous two sentences are probably good enough and I can drop the mention of a SIM I guess. The SIM detail matters more to other SCSI developers, it is less relevant to non-developers.

62

It's related to the comment at the bottom of the file ("No newline at end of file"), somehow I ended up without a newline at the end (which is definitely unusual).

[jhb]

Various review feedback fixes

[salvadore]

I approve. But there is still the issue of the filename markup, so please allow a bit more time for @carlavilla to reply to this.

website/content/en/status/report-2023-04-2023-06/nvmf.adoc

31–32

I would add the markup even if the link is dead. The formatting would be more consistent and, if I understood correctly, the manpage will exist in the future.

But it is not a requirement: if you believe that avoiding the link is better feel free to avoid it.

[carlavilla]

In files we use [.filename]#/etc#

[jhb]

Use filename markup