On Wed, Mar 16, 2016 at 05:05:19PM +0200, Michael S. Tsirkin wrote: > > > > NFS and netperf are the first two protocols I looked > > > > at and both transmit address information across the connection... > > > > > > > > > Does netperf really attempt to get local IP > > > and then send that inline within the connection? > > > > Yes, netperf has separate control and data sockets. I think part of the > > reason for this split is that the control connection can communicate the > > address details for the data connection over a different protocol (TCP + > > RDMA?), but I'm not sure. > > > > Stefan > > Thinking about it, netperf does not survive disconnects. > So the current protocol would be useless for it. > I am not sure about NFS but from (long past) experience it did not > attempt to re-resolve the name to address, so changing an > address would break it as well. > > So I think these applications would have to use a 64 bit CID. > > Why, then, do we care about one aspect of these applications > (creating connections) and not another (not breaking them)? I care about mapping the semantics of AF_VSOCK to virtio-vsock. AF_VSOCK was implemented with the ability to plug in additional transports (like virtio). This allows guest agents and other applications to compile once and run on any transport. If we change virtio-vsock to rely on unique addresses across migration then we lose zero-configuration. AF_VSOCK applications use the VMADDR_CID_HOST (2) constant to communicate with the host. After live migration this well-known CID refers to the new host. Applications would need to know a unique host CID in order to work correctly across live migration. Although I appreciate your drive to make the device as flexible as possible, if we want to do this we are totally beyond AF_VSOCK semantics and would be better served by a separate effort that avoids confusion between class AF_VSOCK semantics and virtio socket semantics. Can we please treat AF_VSOCK semantics as the requirements we're trying to implement? It supports qemu-guest-agent and as I described in a previous mail could also support transparent connection migration a la CRIU sockets. Stefan
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
