On 10/03/21 22:41, Jing Zhang wrote:
I would prefer a completely different interface, where you have a file
descriptor that can be created and associated to a vCPU or VM (or even
to /dev/kvm). Having a file descriptor is important because the fd can
be passed to a less-privileged process that takes care of gathering the
metrics
Separate file descriptor solution is very tempting. We are still considering it
seriously. Our biggest concern is that the metrics gathering/handling process
is not necessary running on the same node as the one file descriptor belongs to.
It scales better to pass metrics data directly than to pass file descriptors.
If you want to pass metrics data directly, you can just read the file
descriptor from your VMM, just like you're using the ioctls now.
However the file descriptor also allows a privilege-separated same-host
interface.
4 bytes flags (always zero)
4 bytes number of statistics
4 bytes offset of the first stat description
4 bytes offset of the first stat value
stat descriptions:
- 4 bytes for the type (for now always zero: uint64_t)
- 4 bytes for the flags (for now always zero)
- length of name
- name
statistics in 64-bit format
The binary format presented above is very flexible. I understand why it is
organized this way.
In our situation, the metrics data could be pulled periodically as short as
half second. They are used by different kinds of monitors/triggers/alerts.
To enhance efficiency and reduce traffic caused by metrics passing, we
treat all metrics info/data as two kinds. One is immutable information,
which doesn't change in a given system boot. The other is mutable
data (statistics data), which is pulled/transferred periodically at a high
frequency.
The format allows to place the values before the descriptions. So you
could use pread to only read the first part of the file descriptor, and
the file_operations implementation would then skip the work of building
the immutable data. It doesn't have to be implemented from the
beginning like that, but the above format supports it.
Paolo
