nvme: add host-discovery-log command #2720
Conversation
ikegami-t
force-pushed
the
nvme2.1-hd-log
branch
from
a78d4e3 to
1e5e709
Compare
|
The changes depended on the libnvme PR linux-nvme/libnvme#961. |
Include nvmf_exat_ptr_next export. Signed-off-by: Tokunori Ikegami <[email protected]>
Since added the NVMe 2.1 log page. Signed-off-by: Tokunori Ikegami <[email protected]>
Since copied from the exsisting completion but missed to change. Signed-off-by: Tokunori Ikegami <[email protected]>
Both bash and zsh completions updated for the command. Signed-off-by: Tokunori Ikegami <[email protected]>
|
There is already code for printing the discovery log: And the print out can be triggered via |
ikegami-t
force-pushed
the
nvme2.1-hd-log
branch
from
93f8b91 to
79f441e
Compare
|
The nvme_show_discovery_log() prints the discovery log page (log identifier 70h) but this command outputs the host discovery log page (log identifier 71h). Sorry I am not sure if the nvme discover command can be added the host discovery log page (log indentifier 71h) or not so just added the command in nvme.c directly but not added in fabrics.c. |
|
Updated the changes to bump the libnvme. |
|
Ah I see. So this is something for the MI based devices then. |
| ----------- | ||
| Retrieve Host Discovery Log, show it | ||
|
|
||
| The <device> parameter is mandatory NVMe character device (ex: /dev/nvme0). |
There was a problem hiding this comment.
The spec says The Host Discovery log page shall not be supported by controllers that expose namespaces for NVMe over PCIe or NVMe over Fabrics thus the kernel will not expose a /dev/nvme0 interface for this, right? I assume this for MI devices.
There was a problem hiding this comment.
Yes seems so if the MI devices supported by the discovery controller but actually I have not seen the MI devices. So is it okay to fix the documentation description example /dev/nvme0 to mctp:<net>,<eid>[:ctrl-id] supported by the discovery controller? But I am thinking also to fix the command as the nvme discover command as you mentioned for now since the command can be specified the discovery controller device actually. Is it okay to be done separately later?
There was a problem hiding this comment.
For now just updated the documentation description to change the NVMe character device to the MI device.
Added the nvme-host-discovery-log.txt file. Signed-off-by: Tokunori Ikegami <[email protected]>
ikegami-t
force-pushed
the
nvme2.1-hd-log
branch
from
79f441e to
0bdaa1a
Compare
|
@jk-ozlabs could have a look here? I think it's correct now but I don't have any MI devices to play with so can't even test it. |
|
I haven't dealt with discovery controllers previously, so can't provide much input on the command implementation, but this seems to be fine in regards to the existing log page support that is used on MI. We have the base MI command supported in libnvme's However, how has this been tested? you mention you don't have access to MI devices... |
The print code can be tested with the test data for debugging locally and the get log page command itself can be ensured as other get log page identifier supported already then the command added can be made sure basically I think. |
I don't have many devices to test on. Sometimes it would be helpful but luckily there are many users reporting any regression pretty fast :) |
|
Thanks! |
oh, that was more for @ikegami-t . Maybe we should hook you up with a bit of a MCTP test environment? :) |
|
I wonder if we could setup something similar to the nightly build. Need to talk to @MaisenbacherD about this :) |
|
Just started to study MCTP as searched the pages below by Google and confirmed already cloned the github mctp repository and built the mctp but unfortunately looks I do not have the MCTP environment host PC and device drive locally (also two drives broken before..). Anyway I will do study more later. Thank you. |
3 participants
Since added the NVMe 2.1 log page.