[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Stratos-dev] Enabling hypervisor agnosticism for VirtIO backends
AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx> writes: > Hi François, > > On Thu, Aug 12, 2021 at 09:55:52AM +0200, Fran??ois Ozog wrote: >> I top post as I find it difficult to identify where to make the comments. > > Thank you for the posting. > I think that we should first discuss more about the goal/requirements/ > practical use cases for the framework. > >> 1) BE acceleration >> Network and storage backends may actually be executed in SmartNICs. As >> virtio 1.1 is hardware friendly, there may be SmartNICs with virtio 1.1 PCI >> VFs. Is it a valid use case for the generic BE framework to be used in this >> context? >> DPDK is used in some BE to significantly accelerate switching. DPDK is also >> used sometimes in guests. In that case, there are no event injection but >> just high performance memory scheme. Is this considered as a use case? > > I'm not quite familiar with DPDK but it seems to be heavily reliant > on not only virtqueues but also kvm/linux features/functionality, say, > according to [1]. > I'm afraid that DPDK is not suitable for primary (at least, initial) > target use. > # In my proposal, virtio-proxy, I have in mind the assumption that we would > # create BE VM as a baremetal application on RTOS (and/or unikernel.) > > But as far as virtqueue is concerned, I think we can discuss in general > technical details as Alex suggested, including: > - sharing or mapping memory regions for data payload > - efficient notification mechanism > > [1] https://www.redhat.com/en/blog/journey-vhost-users-realm > >> 2) Virtio as OS HAL >> Panasonic CTO has been calling for a virtio based HAL and based on the >> teachings of Google GKI, an internal HAL seem inevitable in the long term. >> Virtio is then a contender to Google promoted Android HAL. Could the >> framework be used in that context? > > In this case, where will the implementation of "HAL" reside? > I don't think the portability of "HAL" code (as a set of virtio BEs) > is a requirement here. When I hear people referring to VirtIO HALs I'm thinking mainly of VirtIO FE's living in a Linux kernel. There are certainly more devices that can get added but the commonality on the guest side I think is pretty much a solved problem (modulo Linux-ism's creeping into the virtio spec). -- Alex Bennée
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |