[LU-5960] Add ability to get peer and connection information from lnetctl

• Status: Open
• Project: Lustre
• Affects Version/s: Lustre 2.8.0
• Type: Improvement
• Priority: Minor
• Reporter: James A Simmons
• Assignee: James A Simmons
• Resolution: Unresolved
• Labels: lnet
• Project: Dynamic LNET Configuration

Description

The lnetctl utility added the ability get get new information such as peer credits. What is still lacking is gathering details about peers and connections. This work adds this functionality

Issue Links

• is related to: LU-9667 LNet Kernel/Userspace Interface
• is related to: LU-7734 LNet Multi-Rail Project
• is related to: LU-9119 LNet Multi-Rail Dynamic Discovery pre...
• is related to: LU-10003 lnetctl error "cannot add network: in...
• is related to: LU-5881 Allow hostnames in NID
• is related to: LU-7245 Improve SMP scaling support for LND d...

Comments

[James A Simmons]

Patch at http://review.whamcloud.com/#/c/8027. This is not the final patch but something for feed back. Currently the peer information works well but connection data is currently not working. Need to add man pages and docs for this.

[Peter Jones]

Amir

Could you please review this initial patch

Thanks

Peter

[James A Simmons]

The patch is now in a form that is useful. I like to have feedback from people about the format of lnetctl peers show and conns show commands. Of course code review is welcomed.

http://review.whamcloud.com/#/c/8027

[James A Simmons]

Updated this work for 2.9. I have increased the scope of this patch with the goal of lnetctl having the functionality missing from lctl. As a bonus I added new features to those class functions such as filtering the results based on NID, PID or LNet type. So you could say list
peers for o2ib3 only or another example is listing peers which use PID 5463 instead of the standard lustre PID of 12345.

[James A Simmons]

Updated the patch again. This time I added a new feature which is if a hostname exist for a IP the lnetctl tools can display the hostname instead of the IP. Should we make that optional? Also currently it displays hostname.domainname@nettype. Would admins prefer a hostname@netype as the default?

[Amir Shehata (Inactive)]

James, I think if we do that we should make this feature symmetrical. The intention is to use the YAML output from show commands to be fed directly into YAML configuration. So all YAML config APIs should be able to take a hostname.domainname@nettype and convert that into <ip>@nettype before sending to the Kernel.

I also think we should stick with the shortest non-ambiguous form. Can two nodes be on different domains and have the same hostname? If so (which I think is a possible setting) then we should stick with hostname.domainname@nettype.

[Amir Shehata (Inactive)]

Please note that this is being done under the sysfs project: LU-9667