Re: [PATCH net-next 09/15] net/smc: introduce loopback-ism statistics attributes

From: Wenjia Zhang
Date: Fri Feb 23 2024 - 09:13:46 EST




On 20.02.24 03:45, Wen Gu wrote:


On 2024/2/16 22:24, Wenjia Zhang wrote:


On 11.01.24 13:00, Wen Gu wrote:
This introduces some statistics attributes of loopback-ism. They can be
read from /sys/devices/virtual/smc/loopback-ism/{xfer_tytes|dmbs_cnt}.

Signed-off-by: Wen Gu <guwen@xxxxxxxxxxxxxxxxx>
---
  net/smc/smc_loopback.c | 74 ++++++++++++++++++++++++++++++++++++++++++
  net/smc/smc_loopback.h | 22 +++++++++++++
  2 files changed, 96 insertions(+)


I've read the comments from Jiri and your answer. I can understand your thought. However, from the perspective of the end user, it makes more sense to integetrate the stats info into 'smcd stats'. Otherwise, it would make users confused to find out with which tool to check which statisic infornation. Sure, some improvement of the smc-tools is also needed

Thank you Wenjia.

Let's draw an analogy with RDMA devices, which is used in SMC-R. If we want
to check the RNIC status or statistics, we may use rdma statistic command, or
ibv_devinfo command, or check file under /sys/class/infiniband/mlx5_0. These
provide details or attributes related to *devices*.

Since s390 ISM can be used out of SMC, I guess it also has its own way (other
than smc-tools) to check the statistic?

What we can see in smcr stats or smcd stats command is about statistic or
status of SMC *protocol* layer, such as DMB status, Tx/Rx, connections, fallbacks.

If we put the underlying devices's statistics into smc-tools, should we also
put RNIC statistics or s390 ISM statistics into smcr stat or smcd stat? and
for each futures device that can be used by SMC-R/SMC-D, should we update them
into smcr stat and smcd stat? And the attributes of each devices may be different,
should we add entries in smcd stat for each of them?

After considering the above things, I believe that the details of the underlying
device should not be exposed to smc(smc-tools). What do you think?

Thanks!

That is a very good point. It really depends on how we understand *devices* and how we want to use it. The more we are thinking, the more complicated the thing is getting. I'm trying to find accurate definitions on modeling virtual devices hoping that would make things eaiser. Unfortunately, it is not easy. Finally, I found this article: https://lwn.net/Articles/645810/ (Heads up! It is even from nine years ago, I'm not sure how reliable it is.) With the insight of this article, I'm trying to summarize my thought:

It looks good to put the loopback-ism under the /sys/devices/virtual, especially according to the article
"
.. it is simply a place to put things that don't belong anywhere else.
"
However, in practice we use this in the term of simulated ism, which includes not only loopback-ism, but also other ones. Thus, does it not make sense to classify all of them together? E.g. same bus (just a half-baked idea)

Then the following questions are comig up:
- How should we organize them?
- Should it show up in the smc_rnics?
- How should it be seen from the perspective of the container?
- If we see this loopback-ism as a *device*, should we not only put the device related information under the /sys? Thus, dmbs_cnt seems ok, but xfer_tytes not. Besides, we have a field in smd stat naming "Data transmitted (Bytes)", which should be suitable for this information.