ipc4: handler: Kconfig option to add IPC processing timing prints#9897
ipc4: handler: Kconfig option to add IPC processing timing prints#9897lgirdwood merged 1 commit intothesofproject:mainfrom
Conversation
jsarha
requested review from
dbaluta,
kv2019i,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
| #ifdef CONFIG_DEBUG_IPC_TIMINGS | ||
| tr_info(&ipc_tr, "tx-reply\t: %#x|%#x to %#x|%#x in %llu us", msg_reply.header, | ||
| msg_reply.extension, req.primary.dat, req.extension.dat, | ||
| k_cyc_to_us_near64(sof_cycle_get_64() - tstamp)); |
There was a problem hiding this comment.
this function only prepares IPCs and ipc4_send_reply() below only queues them, they're actually sent in ipc_send_queued_msg() in the IPC work handler. But maybe indeed for our purposes we only need the processing time, not the request-response time, just something to be aware of. So maybe the Kconfig description isn't quite correct - it's not before sending, it's before queuing
There was a problem hiding this comment.
Should this not be E2E timing, i.e we stop the timer when we actually send the reply ?
There was a problem hiding this comment.
Should this not be E2E timing, i.e we stop the timer when we actually send the reply ?
@lgirdwood I guess both are needed for different kinds of analysis - depending on what we want to measure.
Kconfig option DEBUG_IPC_TIMINGS to add logging after IPC handling before putting IPC reply to send queue. The logging contains both the reply and the original request message headers and the time that it took to process the request in micro seconds. The value can be used to collect statistics on changes in firmware response times. This also disables the logging of the received request on core 0 to avoid flooding the logs too much. Signed-off-by: Jyri Sarha <jyri.sarha@linux.intel.com>
jsarha
force-pushed
the
ipc_handling_times
branch
from
a09df34 to
f4ec37c
Compare
|
Update commit message and Kconfig description to better describe what the commit does. |
lyakh
left a comment
lyakh
left a comment
There was a problem hiding this comment.
This can bw used as is to get actual processing times, without response queue draining time
3 participants
Kconfig option DEBUG_IPC_TIMINGS to add logging after IPC handling right before sending IPC reply. The logging contains both the reply and the original request message headers and the time that it took to process the request in micro seconds. The value can be used to collect statistics on changes in firmware response times. This also disables the logging of the received request on core 0 to avoid flooding the logs too much.