[virt-tools-list] vhostmd - virtio channel support

[Jim Fehlig]

On 06/08/2018 05:58 AM, Trapp, Michael wrote:
> On 08.06.18, 10:31, "Daniel P. Berrangé" <berrange at redhat.com> wrote:
> 
>      On Thu, Jun 07, 2018 at 04:23:32PM -0600, Jim Fehlig wrote:
>      > On 06/07/2018 09:42 AM, Trapp, Michael wrote:
>      > > I fully understand the requirements regarding coding style and the way the changes should be split and discussed in detail,
>      > > but may I ask you to provide some general feedback about the basic concept and if this an option at all before we start discussing the details.
>      >
>      > vhostmd already supports 'vbd' and 'xenstore' as transports for the metric
>      > data. Adding another virtio-channel based transport is a great idea IMO.
>      >
>      > WRT writing the data to the various channels, I suppose it is possible to do
>      > that even if there is no (immediate) recipient for the data? The vbd and
>      > xenstore transports don't have a protocol so to speak. The data is simply
>      > written to the disk or xenstore node regardless if there is someone to
>      > consume it. Can the virtio transport work the same? If so, that would
>      > alleviate the need for polling all the fds and the static list of
>      > epoll_event. In virtio_metrics_update() we could simply connect to all the
>      > channels, write the data, close them, and repeat on the next update period
>      > (which is every 5sec by default).
>      
>      Why push it to the guest at a fixed frequency, rather than just letting the
>      guest query the host at whatever rate it feels it needs ?
>      
> content on virtio channel is not discarded. I've setup a simple test and a continuous write on host side blocks when ~123kB are buffered from OS + QEMU.

Ok, we definitely don't want to mindlessly stuff data in the channel from the 
host side :-).

> A delayed read on the VM side contains the whole buffered data.
> Looks like the virtio based approach needs a query from the VM to guarantee that the VM get's the current metrics.

Agreed. Would be nice to avoid the MAX_CHANNELS build-time limit. If nothing 
else it could be a config file option.

Regards,
Jim