mbox series

[v2,0/2] Add SCMI full message tracing

Message ID 20220630173135.2086631-1-cristian.marussi@arm.com (mailing list archive)
Headers show
Series Add SCMI full message tracing | expand

Message

Cristian Marussi June 30, 2022, 5:31 p.m. UTC
Hi,

after a few recent troubles handling too strictly out-of-spec replies from
SCMI servers deployed in the wild, I though it could have been useful to
have a basic way to dump at will the effective full payloads of
successfully transmitted/received SCMI messages.

The existing SCMI traces already collect a bunch of information about SCMI
message exchanges but they do NOT keep any payload information: this is
certainly preferable most of the time since dumping full SCMI messages to
the trace buffer involves a full copy of the payload.

For this reason I added a new distinct trace_scmi_msg_dump with this series
in order to be able to selectively enable at will message dumping only when
required.

Only successfully transmitted and received (valid) xfers are dumped.

Following the advice from Jim, I added some parsing/interpretation of the
header, so that the final result is something like:

root@deb-guest:~# echo 1 > /sys/kernel/debug/tracing/events/scmi/scmi_msg_dump/enable 
root@deb-guest:~# cat /sys/kernel/debug/tracing/trace_pipe 

 ++ cmd/reply
    sugov:0-257     [000] .....   401.954788: scmi_msg_dump: pt=13 t=CMND msg_id=07 seq=0082 s=0 pyld=0000000000000000
     <idle>-0       [000] d.h2.   401.955085: scmi_msg_dump: pt=13 t=RESP msg_id=07 seq=0082 s=0 pyld=


 ++ cmd/reply/delayed
   cat-263     [001] .....   471.533806: scmi_msg_dump: pt=15 t=CMND msg_id=06 seq=008A s=0 pyld=0100000001000000
<idle>-0       [000] d.h2.   471.554001: scmi_msg_dump: pt=15 t=RESP msg_id=06 seq=008A s=0 pyld=
<idle>-0       [000] d.h2.   471.574102: scmi_msg_dump: pt=15 t=DLYD msg_id=06 seq=008A s=0 pyld=01000000a05a320000000000efbeaddefecafeca


 ++ enable notif/notif
iio_generic_buf-282     [000] .....   535.327307: scmi_msg_dump: pt=15 t=CMND msg_id=0A seq=00AB s=0 pyld=0800000003000000
         <idle>-0       [000] d.h2.   535.327561: scmi_msg_dump: pt=15 t=RESP msg_id=0A seq=00AB s=0 pyld=00000000
         <idle>-0       [000] d.h2.   535.334421: scmi_msg_dump: pt=15 t=NOTI msg_id=01 seq=0000 s=0 pyld=000000000800000008daffffffffffff008268d4c075fd1610daffffffffffff008268d4c075fd1618daffffffffffff008268d4c075fd16
         <idle>-0       [000] d.h2.   535.434649: scmi_msg_dump: pt=15 t=NOTI msg_id=01 seq=0000 s=0 pyld=000000000800000009daffffffffffff008268d4c075fd1611daffffffffffff008268d4c075fd1619daffffffffffff008268d4c075fd16

Payload is dumped as it comes through byte-by-byte without any endianity
conversion to avoid further load on the system.

Thanks,
Cristian

---
V1 --> V2
- changed dumping format

Cristian Marussi (2):
  include: trace: Add SCMI full message tracing
  firmware: arm_scmi: Use new SCMI full message tracing

 drivers/firmware/arm_scmi/driver.c | 21 ++++++++++++++++++++
 include/trace/events/scmi.h        | 31 ++++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+)

Comments

Sudeep Holla July 1, 2022, 1:54 p.m. UTC | #1
On Thu, Jun 30, 2022 at 06:31:33PM +0100, Cristian Marussi wrote:
> Hi,
> 
> after a few recent troubles handling too strictly out-of-spec replies from
> SCMI servers deployed in the wild, I though it could have been useful to
> have a basic way to dump at will the effective full payloads of
> successfully transmitted/received SCMI messages.
> 
> The existing SCMI traces already collect a bunch of information about SCMI
> message exchanges but they do NOT keep any payload information: this is
> certainly preferable most of the time since dumping full SCMI messages to
> the trace buffer involves a full copy of the payload.
> 
> For this reason I added a new distinct trace_scmi_msg_dump with this series
> in order to be able to selectively enable at will message dumping only when
> required.
> 
> Only successfully transmitted and received (valid) xfers are dumped.

Looks good to me. I would like to hear from Jim if possible. I plan to
merge this ASAP.
Jim Quinlan July 1, 2022, 3:03 p.m. UTC | #2
Hi,
LGTM, I appreciate this change. For testing, I fed  your sample output to this:

     perl -MData::Dumper -nae  's/^.+scmi_msg_dump:// && print Dumper
{ (map { split /=/; } split" ") }' < scmi.txt

which gives this

$VAR1 = {
          'pt' => '15',
          'seq' => '0000',
          'pyld' =>
'000000000800000009daffffffffffff008268d4c075fd1611daffffffffffff008268d4c075fd1619daffffffffffff008268d4c075fd16',
          'msg_id' => '01',
          's' => '0',
          't' => 'NOTI'
        };
which is what I wanted.   BTW, if I ever write a script that would
take this SCMI trace text and
decode it to nice cmd names and arguments -- where would I submit such a script?

Thanks and Regards,
Jim Quinlan
Broadcom STB


On Fri, Jul 1, 2022 at 9:54 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Thu, Jun 30, 2022 at 06:31:33PM +0100, Cristian Marussi wrote:
> > Hi,
> >
> > after a few recent troubles handling too strictly out-of-spec replies from
> > SCMI servers deployed in the wild, I though it could have been useful to
> > have a basic way to dump at will the effective full payloads of
> > successfully transmitted/received SCMI messages.
> >
> > The existing SCMI traces already collect a bunch of information about SCMI
> > message exchanges but they do NOT keep any payload information: this is
> > certainly preferable most of the time since dumping full SCMI messages to
> > the trace buffer involves a full copy of the payload.
> >
> > For this reason I added a new distinct trace_scmi_msg_dump with this series
> > in order to be able to selectively enable at will message dumping only when
> > required.
> >
> > Only successfully transmitted and received (valid) xfers are dumped.
>
> Looks good to me. I would like to hear from Jim if possible. I plan to
> merge this ASAP.
>
> --
> Regards,
> Sudeep
Sudeep Holla July 1, 2022, 3:13 p.m. UTC | #3
On Fri, Jul 01, 2022 at 11:03:38AM -0400, Jim Quinlan wrote:
> Hi,
> LGTM, I appreciate this change. For testing, I fed  your sample output to this:
>

Thanks!

>      perl -MData::Dumper -nae  's/^.+scmi_msg_dump:// && print Dumper
> { (map { split /=/; } split" ") }' < scmi.txt
> 
> which gives this
> 
> $VAR1 = {
>           'pt' => '15',
>           'seq' => '0000',
>           'pyld' =>
> '000000000800000009daffffffffffff008268d4c075fd1611daffffffffffff008268d4c075fd1619daffffffffffff008268d4c075fd16',
>           'msg_id' => '01',
>           's' => '0',
>           't' => 'NOTI'
>         };
> which is what I wanted.   BTW, if I ever write a script that would
> take this SCMI trace text and
> decode it to nice cmd names and arguments -- where would I submit such a script?
>

I am not 100% sure. After reading this, the first thoughts were scripts/
or tools/scripts but looking at the content I am less sure about latter.
Worth posting and then check what people have to say once this lands upstream.
Or even once this is merged into -next officially.
Sudeep Holla July 6, 2022, 9:39 a.m. UTC | #4
On Thu, 30 Jun 2022 18:31:33 +0100, Cristian Marussi wrote:
> after a few recent troubles handling too strictly out-of-spec replies from
> SCMI servers deployed in the wild, I though it could have been useful to
> have a basic way to dump at will the effective full payloads of
> successfully transmitted/received SCMI messages.
> 
> The existing SCMI traces already collect a bunch of information about SCMI
> message exchanges but they do NOT keep any payload information: this is
> certainly preferable most of the time since dumping full SCMI messages to
> the trace buffer involves a full copy of the payload.
> 
> [...]

Applied to sudeep.holla/linux (for-next/scmi), thanks!

[1/2] include: trace: Add SCMI full message tracing
      https://git.kernel.org/sudeep.holla/c/2bd0467074
[2/2] firmware: arm_scmi: Use new SCMI full message tracing
      https://git.kernel.org/sudeep.holla/c/b60e088682

--
Regards,
Sudeep