Re: [PATCH] AF_VMCHANNEL address family for guest<->host communication.

On Mon, 15 Dec 2008 17:01:14 -0600
Anthony Liguori [off-list ref] wrote:

David Miller wrote:

quoted

From: Anthony Liguori <redacted>
Date: Mon, 15 Dec 2008 14:44:26 -0600

  

quoted

We want this communication mechanism to be simple and reliable as we
want to implement the backends drivers in the host userspace with
minimum mess.
    

One implication of your statement here is that TCP is unreliable.
That's absolutely not true.
  

No, TCP falls under the not simple category because it requires the 
backend to have access to a TCP/IP stack.

quoted

quoted

Within the guest, we need the interface to be always available and
we need an addressing scheme that is hypervisor specific.  Yes, we
can build this all on top of TCP/IP.  We could even build it on top
of a serial port.  Both have their down-sides wrt reliability and
complexity.
    

I don't know of any zero-copy through the hypervisor mechanisms for
serial ports, but I know we do that with the various virtualization
network devices.
  

Yes, and I went down the road of using a dedicated network device and 
using raw ethernet as the protocol.  The thing that killed that was the 
fact that it's not reliable.  You need something like TCP to add 
reliability.

But that's a lot of work and a bit backwards.  Use a unreliable 
transport but use TCP on top of it to get reliability.  Our link 
(virtio) is inherently reliable so why not just expose a reliable 
interface to userspace?

quoted

quoted

Do you have another recommendation?
    

I don't have to make alternative recommendations until you can
show that what we have can't solve the problem acceptably, and
TCP emphatically can.
  

It can solve the problem but I don't think it's the best way to solve 
the problem mainly because the complexity it demands on the backend.

"Those who don't understand TCP are doomed to reimplement it, badly."