Re: [virtio-dev] Zerocopy VM-to-VM networking using virtio-net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24 April 2015 at 15:22, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote:
The motivation for making VM-to-VM fast is that while software
switches on the host are efficient today (thanks to vhost-user), there
is no efficient solution if the software switch is a VM.

I see. This sounds like a noble goal indeed. I would love to run the software switch as just another VM in the long term. It would make it much easier for the various software switches to coexist in the world.

The main technical risk I see in this proposal is that eliminating the memory copies might not have the desired effect. I might be tempted to keep the copies but prevent the kernel from having to inspect the vrings (more like vhost-user). But that is just a hunch and I suppose the first step would be a prototype to check the performance anyway.

For what it is worth here is my view of networking performance on x86 in the Haswell+ era:
https://groups.google.com/forum/#!topic/snabb-devel/aez4pEnd4ow

Have you had requests to run SnabbSwitch in a VM instead of on the
host?

This is not something we have discussed.

I can say that I am not satisfied with our installation process on the host. I want this to be trivially easy, but it is not.

On the one hand we make some parts easy: we only require one executable file (~1.5MB) and it works on any modern distro and kernel.

On the other hand we require the user to edit grub.conf to reserve cores and keep the IOMMU out of the way, and to manually run a traffic process for each 10G port pinned to a suitable core. That requires a bunch of downstream work.

Gory details:
https://github.com/SnabbCo/snabb-nfv/wiki/Compute-node-requirements

This should be much simpler. I would quite like to be able to wrap this up in a VM or a container. The risk is that then we become dependent on other systems (e.g. OpenStack) pinning cores correctly, etc, and that might be placing unrealistic expectations on the orchestration systems of the present and near future (?). I mean: if we make this somebody else's problem, we had better trust that they will do it right.

Cheers,
-Luke


_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux