From: Wenjia Zhang <wenjia@linux.ibm.com>
To: Wen Gu <guwen@linux.alibaba.com>,
wintera@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
agordeev@linux.ibm.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, jaka@linux.ibm.com
Cc: borntraeger@linux.ibm.com, svens@linux.ibm.com,
alibuda@linux.alibaba.com, tonylu@linux.alibaba.com,
linux-s390@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 09/15] net/smc: introduce loopback-ism statistics attributes
Date: Fri, 23 Feb 2024 15:13:18 +0100 [thread overview]
Message-ID: <700198c8-e4dc-4974-9ebf-f819deaa785b@linux.ibm.com> (raw)
In-Reply-To: <cac6192e-85d8-4289-b5af-bc8143e76004@linux.alibaba.com>
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@linux.alibaba.com>
>>> ---
>>> 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.
next prev parent reply other threads:[~2024-02-23 14:13 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 12:00 [PATCH net-next 00/15] net/smc: implement loopback-ism used by SMC-D Wen Gu
2024-01-11 12:00 ` [PATCH net-next 01/15] net/smc: improve SMC-D device dump for virtual ISM Wen Gu
2024-01-11 12:00 ` [PATCH net-next 02/15] net/smc: decouple specialized struct from SMC-D DMB registration Wen Gu
2024-01-11 12:00 ` [PATCH net-next 03/15] net/smc: introduce virtual ISM device loopback-ism Wen Gu
2024-02-16 14:11 ` Wenjia Zhang
2024-02-20 1:20 ` Wen Gu
2024-01-11 12:00 ` [PATCH net-next 04/15] net/smc: implement ID-related operations of loopback-ism Wen Gu
2024-01-11 12:00 ` [PATCH net-next 05/15] net/smc: implement some unsupported " Wen Gu
2024-01-11 12:00 ` [PATCH net-next 06/15] net/smc: implement DMB-related " Wen Gu
2024-02-16 14:13 ` Wenjia Zhang
2024-02-20 1:55 ` Wen Gu
2024-02-23 14:12 ` Wenjia Zhang
2024-02-26 3:04 ` Wen Gu
2024-01-11 12:00 ` [PATCH net-next 07/15] net/smc: register loopback-ism into SMC-D device list Wen Gu
2024-01-11 12:00 ` [PATCH net-next 08/15] net/smc: introduce loopback-ism runtime switch Wen Gu
2024-01-11 12:00 ` [PATCH net-next 09/15] net/smc: introduce loopback-ism statistics attributes Wen Gu
2024-02-16 14:24 ` Wenjia Zhang
2024-02-20 2:45 ` Wen Gu
2024-02-23 14:13 ` Wenjia Zhang [this message]
2024-02-26 12:58 ` Wen Gu
2024-01-11 12:00 ` [PATCH net-next 10/15] net/smc: add operations to merge sndbuf with peer DMB Wen Gu
2024-01-11 12:00 ` [PATCH net-next 11/15] net/smc: attach or detach ghost sndbuf to " Wen Gu
2024-01-11 12:00 ` [PATCH net-next 12/15] net/smc: adapt cursor update when sndbuf and peer DMB are merged Wen Gu
2024-01-11 12:00 ` [PATCH net-next 13/15] net/smc: introduce loopback-ism DMB type control Wen Gu
2024-02-16 14:25 ` Wenjia Zhang
2024-02-20 3:19 ` Wen Gu
2024-01-11 12:00 ` [PATCH net-next 14/15] net/smc: introduce loopback-ism DMB data copy control Wen Gu
2024-01-12 16:24 ` Niklas Schnelle
2024-01-13 7:12 ` Wen Gu
2024-02-16 14:25 ` Wenjia Zhang
2024-02-20 3:36 ` Wen Gu
2024-02-23 14:42 ` Wenjia Zhang
2024-01-11 12:00 ` [PATCH net-next 15/15] net/smc: implement DMB-merged operations of loopback-ism Wen Gu
2024-01-11 13:36 ` [PATCH net-next 00/15] net/smc: implement loopback-ism used by SMC-D Simon Horman
2024-01-12 2:54 ` Wen Gu
2024-01-11 14:50 ` Jiri Pirko
2024-01-12 8:29 ` Wen Gu
2024-01-12 9:10 ` Jiri Pirko
2024-01-12 12:32 ` Wen Gu
2024-01-12 15:50 ` Jiri Pirko
2024-01-13 9:22 ` Wen Gu
2024-01-15 14:11 ` Jiri Pirko
2024-01-18 8:27 ` Wen Gu
2024-01-18 13:59 ` Wenjia Zhang
2024-01-19 1:46 ` Wen Gu
2024-01-23 14:03 ` Alexandra Winter
2024-01-24 6:33 ` Wen Gu
2024-02-05 10:05 ` Wen Gu
2024-02-07 9:08 ` Wenjia Zhang
2024-02-06 12:18 ` Alexandra Winter
2024-02-08 16:12 ` Wen Gu
2024-02-19 14:04 ` Wen Gu
2024-02-16 14:09 ` Wenjia Zhang
2024-02-20 3:52 ` Wen Gu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=700198c8-e4dc-4974-9ebf-f819deaa785b@linux.ibm.com \
--to=wenjia@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=alibuda@linux.alibaba.com \
--cc=borntraeger@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gor@linux.ibm.com \
--cc=guwen@linux.alibaba.com \
--cc=hca@linux.ibm.com \
--cc=jaka@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=svens@linux.ibm.com \
--cc=tonylu@linux.alibaba.com \
--cc=wintera@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox