UCS/DEBUG: Add table builder API

[guy-ealey-morag]

What?

Unify table printing logic under a common API, refactored existing table prints in sys_info.c and proto_debug.c.

Why?

Every feature that prints a table implements its own table formatting logic which is fragile and hard to extend.
A unified API would make printing new tables easier and would unify behavior across UCX.

This refactor was done to allow me print new tables as part of a new feature I'm working on.

Examples:

UCX_PROTO_INFO=used

+--------+-----------+-----------------------------------------------+-------------+
| perftest self cfg#0                                                              |
| active message by ucp_am_send*(multi) from host memory                           |
+--------+-----------+-----------------------------------------------+-------------+
| Count  |   Range   |                  Description                  |   Config    |
+--------+-----------+-----------------------------------------------+-------------+
|      0 |   0..2434 | short                                         | self/memory |
| 516383 | 2435..inf | (?) rendezvous copy from mapped remote memory | self/memory |
+--------+-----------+-----------------------------------------------+-------------+

UCX_PROTO_INFO=y

+--------------+-----------------------------------------------+-------------------+
| perftest self cfg#0                                                              |
| active message by ucp_am_send* with reply flag(fast-completion) from host memory |
+--------------+-----------------------------------------------+-------------------+
|    Range     |                  Description                  |      Config       |
+--------------+-----------------------------------------------+-------------------+
|      0..8176 | short                                         | self/memory       |
| 8177..262143 | multi-frag copy-in                            | self/memory       |
|    256K..inf | (?) rendezvous copy from mapped remote memory | self/memory       |
+--------------+-----------------------------------------------+-------------------+

ucx_info -T

#
# System topology
#
# +---------+---------+---------+---------+---------+---------+
# |         |         |         |         |         |         |
# |    MB/s | ens10f0 |  mlx5_0 |  mlx5_1 |    GPU0 |  mlx5_2 |
# |         |         |         |         |         |         |
# +---------+---------+---------+---------+---------+---------+
# |         |         |         |         |         |         |
# | ens10f0 |    -    | 17000.0 |  5100.0 |  5100.0 |  5100.0 |
# |         |         |         |         |         |         |
# +---------+---------+---------+---------+---------+---------+
# |         |         |         |         |         |         |
# |  mlx5_0 | 17000.0 |    -    |  5100.0 |  5100.0 |  5100.0 |
# |         |         |         |         |         |         |
# +---------+---------+---------+---------+---------+---------+
# |         |         |         |         |         |         |
# |  mlx5_1 |  5100.0 |  5100.0 |    -    | 17000.0 | 17000.0 |
# |         |         |         |         |         |         |
# +---------+---------+---------+---------+---------+---------+
# |         |         |         |         |         |         |
# |    GPU0 |  5100.0 |  5100.0 | 17000.0 |    -    | 17000.0 |
# |         |         |         |         |         |         |
# +---------+---------+---------+---------+---------+---------+
# |         |         |         |         |         |         |
# |  mlx5_2 |  5100.0 |  5100.0 | 17000.0 | 17000.0 |    -    |
# |         |         |         |         |         |         |
# +---------+---------+---------+---------+---------+---------+
#
# NUMA memory latency
#
# +---------+---------+---------+---------+---------+---------+
# |         |         |         |         |         |         |
# |  device | ens10f0 |  mlx5_0 |  mlx5_1 |    GPU0 |  mlx5_2 |
# |         |         |         |         |         |         |
# +---------+---------+---------+---------+---------+---------+
# |         |         |         |         |         |         |
# |    nsec |   210.0 |   210.0 |   210.0 |   210.0 |   210.0 |
# |         |         |         |         |         |         |
# +---------+---------+---------+---------+---------+---------+

[guy-ealey-morag]

@svc-nvidia-pr-review

[svc-nvidia-pr-review]

🤖 Starting review — findings will be posted here when done.

[svc-nvidia-pr-review]

Code Review

9 findings — ⚠️ 7 minors, ℹ️ 2 infos

9 findings posted as inline comments.

[Artemy-Mellanox]

perhaps a more compact API for tables still would be better? since tables are printed based on a special request, not as part of the regular workflow.

[guy-ealey-morag]

That is my preference, the error handling was added after the review of @iyastreb
I tend to think that failing with ucs_fatal or ucs_assertv_always is acceptable because it can be only caused by memory issues or developer error (bad config, bad args).

@iyastreb Can we open it for discussion again?

[iyastreb]

Well, I just provided my feedback, if others think that compact API is better - we can do it. Personally I think that fatal in logging utility is not the best.

Another approach would be to add "ucs_status last_error" field to the table, so that:

• each function checks this field in the beginning, if error is set - just return
• first time we set an error - log ERROR

This way we keep API simple and avoid fatal

[guy-ealey-morag]

@iyastreb I implemented your suggestion, please review