Hi, Forgive me if these questions are obvious, I am not a kernel developer. >From what I am reading here: http://lists.linuxfoundation.org/pipermail/virtualization/2015-December/030935.html The code has been removed from mainline, is it queued for 4.6? If not, when are you planning on re-submitting it?
We now have a vsock transport merged into xpra, which works very well with the kernel and qemu versions found here: http://qemu-project.org/Features/VirtioVsock Congratulations on making this easy to use! Is the upcoming revised interface likely to cause incompatibilities with existing binaries? It seems impossible for the host to connect to a guest: the guest has to initiate the connection. Is this a feature / known limitation or am I missing something? For some of our use cases, it would be more practical to connect in the other direction. In terms of raw performance, I am getting about 10Gbps on an Intel Skylake i7 (the data stream arrives from the OS socket recv syscall split into 256KB chunks), that's good but not much faster than virtio-net and since the packets are avoiding all sorts of OS layer overheads I was hoping to get a little bit closer to the ~200Gbps memory bandwidth that this CPU+RAM are capable of. Am I dreaming or just doing it wrong? In terms of bandwidth requirements, we're nowhere near that level per guest - but since there are lot of guests per host, I use this as a rough guesstimate of the efficiency and suitability of the transport. How hard would it be to introduce a virtio mmap-like transport of some sort so that the guest and host could share some memory region? I assume this would give us the best possible performance when transferring large amounts of data? (we already have a local mmap transport we could adapt) Thanks Antoine
