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

[Cristian Marussi <cristian.marussi@arm.com>]

On Fri, Jun 20, 2025 at 10:27:52AM +0100, Philip Radford wrote:
> 
> 
> > -----Original Message-----
> > From: Peng Fan <peng.fan@oss.nxp.com>
> > Sent: Friday, June 20, 2025 9:47 AM
> > To: Philip Radford <Philip.Radford@arm.com>
> 
> Hi,
> Thanks for the review.
> 

Hi,

> > Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; arm-
> > scmi@vger.kernel.org; Sudeep Holla <Sudeep.Holla@arm.com>; Cristian
> > Marussi <Cristian.Marussi@arm.com>; Luke Parkin <Luke.Parkin@arm.com>
> > Subject: Re: [PATCH 0/4] firmware: arm_scmi: Add xfer inflight debug and
> > trace
> > 
> > On Thu, Jun 19, 2025 at 12:20:00PM +0000, Philip Radford wrote:
> > >Hi all,
> > >
> > >This series adds a new counter to the Arm SCMI firmware driver to track
> > >the number of in-flight message transfers during debug and trace. This
> > >will be useful for examining behaviour under a large load with regards
> > >to concurrent messages being sent and received. As the counter only gives
> > >a live value, printing the value in trace allows logging of the in-flight
> > >xfers.
> > 
> > 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,
Cristian