Hi everyone,
This RFC aims to kick off a discussion about adding ftrace events in
V4L2 and mem2mem in particular.
The goal is to aid both userspace and kernel developers alike by
allowing them to trace their individual application/library and drivers,
respectively.
# Data provided
In order to correlate the components through their lifetime we need a
few unique identifiers:
- minor: the device minor, aka /dev/video
Useful, when multiple devices are present.
- fh: file handle
Allows us to map the buffer, ioctl and mem2mem jobs.
- fh: as a job instance... sort of
We also use it as to distinguish between the different jobs, as long
as we track the cancel/finish events.
Additionally, for buffers we need:
- type: VIDEO_OUTPUT_MPLANE, VIDEO_CAPTURE_MPLANE, etc
- index: buffer index
Each buffer type has its own pool.
# Event list and examples
Generic:
v4l2_ioctl_s_fmt: minor = 0, fh = 5068c670, type = VIDEO_OUTPUT_MPLANE,
width=1280, height=720, ...
v4l2_qbuf: minor = 0, fh = 5068c670, index = 0, type =
VIDEO_CAPTURE_MPLANE, bytesused = 0, ...
v4l2_dqbuf: minor = 0, fh = 5068c670, index = 0, type =
VIDEO_CAPTURE_MPLANE, bytesused = 0, ...
Mem2mem specific:
v4l2_m2m_schedule: minor = 0, fh = 5068c670
v4l2_m2m_schedule_failed: minor = 0, fh = 5068c670, reason = NO_SRC
v4l2_m2m_queue_job: minor = 0, fh = 5068c670, src = 0, dst = 0
Currently src and dst only show the buffer index. Buffer type can be
deduced based on the type of job - encode or decode.
v4l2_m2m_run_job: minor = 0, fh = 5068c670
v4l2_m2m_cancel_job: minor = 0, fh = 5068c670
v4l2_m2m_finish_job: minor = 0, fh = 5068c670
v4l2_m2m_stream_on: minor = 0, fh = 5068c670, type = f9e16c2e
v4l2_m2m_stream_off: minor = 0, fh = 5068c670, type = f9e16c2e
v4l2_m2m_buf_done: minor = 0, fh = 5068c670, index = 0, type =
VIDEO_CAPTURE_MPLANE, state = DONE
# Testing and feasibility
While developing this series I've used them against the recent SAMA5D4
Hantro driver. As result I was able to measure:
- No time differences when switching from hard to soft IRQ
- Seemingly gstreamer issues decoding jobs, even before it has queued
any buffers.
- Notable 1ms queue times, when using gstreamer's new decodebin3
element - relative to 50us when using decodebin.
# Open questions
As you may have noticed, a couple of places are not so friendly to
scripting and external tools. Here is what we can do:
- add additional mem2mem job index identifier, so we can parse traces
without having to track v4l2_m2m_cancel_job or v4l2_m2m_finish_job.
- expand v4l2_m2m_queue_job() to include mode buffer details
{src,dst}_buf { .index = foo, .type = bar, ... }
Thus looking for feedback from the overall community - is this something
we want, do the proposed trace events seem sufficient for your use-case?
Comments and reviews for the individual patches is more than welcome.
Thanks
Emil
Emil Velikov (5):
media: v4l2: print the fh, during qbuf/dqbuf tracing
media: v4l2: add VIDIOC_S_FMT tracing
media: v4l2-mem2mem: add job tracing
media: v4l2-mem2mem: add v4l2_m2m_buf_done trace point
media: v4l2-mem2mem: add v4l2_m2m_stream_on/off tracepoints
drivers/media/v4l2-core/v4l2-ioctl.c | 12 +-
drivers/media/v4l2-core/v4l2-mem2mem.c | 26 ++
drivers/media/v4l2-core/v4l2-trace.c | 11 +
include/media/v4l2-mem2mem.h | 21 +-
include/trace/events/v4l2.h | 357 ++++++++++++++++++++++++-
include/uapi/linux/videodev2.h | 1 +
6 files changed, 411 insertions(+), 17 deletions(-)
--
2.31.1
