Re: [virtio-dev] [PATCH] Add virtio parameter server device specification

[Hao Chen <chenhaosjtuacm@google.com>]

Hi Stefan and Enrico,

> What does "share the same configuration" mean? ...

It means these values share the virtio_parameter_server_prop_config.
So they will have the same mode (e.g., all of them are read-only and static).
Also they have the same encoding rule, for example, each value contains one
64-bit integer and three 64-bit floating point numbers.

> What are the units of this timestamp (nanoseconds, milliseconds,
> seconds)?

I don't know if I should define the unit, in our current usecase,
it can be unix timestamp in milliseconds, but I don't know if it is
true for all potential usecases. Maybe in some cases there will not
be real-world timestamp but using sequential numbers instead. So I
leave it blank here. The reason of having this field is the guest VM
userspace may need to know the order of the generation of the data.
In some cases the guest userspace may also care about the real generation
time. Do you prefer having a clearer definition here?

> A common request layout for devices is:
>
> Âstruct request {
> Â Â Âstruct request_header header;
> Â Â Âu8 data[];
> Â Â Âstruct request_footer footer;
> Â};

I didn't see any "footers" in the current spec. Could you please explain more?

> Can you rephrase the definition of MUTABLE? I don't understand what it
> means, especially since there is already a WRITE permission that
> indicates read-only parameters. Why is MUTABLE needed?

Write permission and mutable variables are different things. For example,
if we use a flag to indicate if it is sunny outside, we cannot write to it
since we cannot control the weather, but the value is definitely mutable
because weather may change.

> Does CONTINUOUS mean that the device expects to update the value?
> ... Âthen PERIODIC might be a clearer name than CONTINUOUS

Both MUTABLE and CONTINUOUS variables may be changed by the device,
but MUTABLE value changes usually represent async value updates (like
IP address changed, gear switched, or weather changed, etc.), the value
need to be send to the driver in every updates; while CONTINOUS values
are more like rated sensor data.

> > +The properties with the same \field{prop_id} share the configuration.

> It is not clear to mean what a "configuration" is.

"configuration" means "virtio_parameter_server_prop_config"


> > \field{min_sample_freq} and
> > +\field{max_sample_freq} are the sampling rate range for the
> > +\field{VIRTIO_PARAMETER_SERVER_M_CONTINUOUS} values.

> Is this really needed since the device interface also supports pub/sub?

It is, those numbers indicate how fast the device will sample the data for
the driver. The driver doesn't fetch the value at the max rate, it just check.

> > \field{desc} is
> > the optional string
> > +description.

> Is this the parameter's name ("temperature_sensor_4") or is it a
> description ("Main board temperature sensor")?

What is the difference? The device use the prop_id to identify parameters
and this is for human anyways.

> > \field{params} are for the customized configuration parameters.

> This looks like a vendor-specific extension mechanism. It's opaque so
> there's no way for the driver to skip over parameters it doesn't
> understand. That could be a problem for version compatibility if the
> device/driver are updated and expect different param[] data formats.
> Perhaps it would help to define the structure that allows the driver to
> skip unknown parameters?

The driver does not care. The driver's behavior is nothing to do with the
configs. The configs are for the userspace to understand the value it
receives. In each specific case, there will be some special "configs" that
the userspace app may need to know, but the driver is still act as a general
parameter server driver.

> On 9P it would just be issuing one Tread per file you're intersted in
> (of course, after Rread comes in, you'll have to send it again, if you
> wanna continue to read).

> How is that so different from subscriptions ?

I have to say I am not familar with 9P, but in our case we don't need to launch
1000+ threads to read on files or open 1000+ fds to poll on them (we literally
have that many properties!). We just process the data from the eventq. Also,
by using a single eventq, we are free from maintaining a data structure like
priority queue to make sure the data is processed in-order.

On Thu, Jun 10, 2021 at 9:06 AM Enrico Weigelt, metux IT consult <lkml@metux.net> wrote:

On 09.06.21 22:30, Hao Chen wrote:
>Â > Why not directly putting 9P links into virtio devices ?
>
> We have thought about using files to represent properties, but it turns
> out we may need to subscribe to a large amount of
> properties, so opening all of those files and polling is not ideal. Also
> the cross-property time-order matters in our case, so we abandoned this
> idea.

On 9P it would just be issuing one Tread per file you're intersted in
(of course, after Rread comes in, you'll have to send it again, if you
wanna continue to read).

How is that so different from subscriptions ?

--mtx

--
---
Hinweis: unverschlÃsselte E-Mails kÃnnen leicht abgehÃrt und manipuliert
werden ! FÃr eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-SchlÃssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287