Re: [PATCH 0/4] firmware: arm_scmi: Add xfer inflight debug and trace

[Peng Fan <peng.fan@oss.nxp.com>]

Hi Cristian,

On Thu, Jun 26, 2025 at 12:37:49PM +0100, Cristian Marussi wrote:
>> > Just a general question, is this counter count in flight messages
>> > for a scmi instance or it is per transport? I ask because
>> > one scmi instance could have multiple mailboxes. If counting based
>> > on scmi instance, it may not be that accurate.
>> > 
>
>... so that is a good point ...
>...thanks Peng for pointing out this first of all...
>
>So, in general all of these counters are per-instance, we don't have any
>finer per-channel granularity....we could in the future split them out
>to be per-channel counters, but I wonder if it would be worth the
>effort: because, as I see it, errors reported by these counters are more
>of a alarm-bell than a triage tool, in the sense that I would expect
>that seeing a lot of errors of some kind on an instance should just act
>as a warning that something is NOT right somewhere, so that you can
>investigate further by enabling the already existent and more comprehensive
>SCMI trace events to fully inveestigate the problem...since SCMI full event
>traces DO also include the used-channel beside a lot of other info about
>the xfer transactions.
>
>Moreover, in the specific case of tracking inflight xfers, note that
>the counter added in this series tracks the pool of xfers allocated in
>tx_minfo(A2P) free-lists (i.e. commands...P2A msgs hardly can be lost),
>BUT this structure is per-instance (NOT per-channel), so even if you had
>say a few more dedicated per-protocol channels defined on a system,
>all the A2P transactions will pick their xfers from the same per-instance
>pool... (..because the max_inflights is meant to cap the maximum number
>of outstanding transactions that the server has to cope with...)

Thanks for explaining this. It is clear that there is no need finer
granularity. Just leave as it is.

Thanks,
Peng

>
>Thanks,
>Cristian