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

[Trapp, Michael]

On 08.06.18, 00:23, "Jim Fehlig" <jfehlig at suse.com> 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).
    
So far I've seen virtio like any other communication like sockets because on the host side it is a UDS
and based on that nonblocking I/O would be an efficient way. UDS should also be reliable like TCP, no data should be dropped
and due to that a writer will block when the data is not cunsumed at the other end of the socket and the buffer is full.
Another reason from my perspective is that we might get in situations where we have to send fragments like with any other socket based communication.

But honestly, I don't know what happens inside QEMU, because that's the other end of the UDS and there might be some special implementation for virtio and the interconnect between UDS and serial-channel
Maybe a QEMU expert on the virt-tool-list can shed some light on that.

If there is no better/simpler alternative to EPOLL I would prepare the patches and send them to the virt-tool-list

Regards,
Michael