On Tue, Jul 26, 2016 at 07:09:41AM +0000, Dexuan Cui wrote: > If you meant https://lkml.org/lkml/2016/7/13/382, I don't think Michal > Kubecek was suggesting I build my code using the existing AF_VSOCK > code(?) I think he was only asking me to clarify the way I used to write > the text to explain why I can't fit my code into the existing AF_VSOCK > code. BTW, AF_VSOCK is not on S390, I think. Actually, I believe building on top of existing AF_VSOCK should be the first thought and only if this way shows unfeasible, one should consider a completely new implementation from scratch. After all, when VMware was upstreaming vsock, IIRC they had to work hard on making it a generic solution rather than a one purpose tool tailored for their specific use case. What I wanted to say in that mail was that I didn't find the reasoning very convincing. The only point that wasn't like "AF_VSOCK has many features we don't need" was the incompatible addressing scheme. The cover letter text didn't convince me it was given as much thought as it deserved. I felt - and it still feel - that the option of building on top of vsock wasn't considered seriously enough. I must also admit I'm a bit confused by your response to the issue of socket lookup performance. I always thought the main reason to use special hypervisor sockets instead of TCP/IP over virtual network devices was efficiency (to avoid the overhead of network protocol processing). The fact that traversing a linear linked list under a global mutex for each socket lookup is not an issue as opening a connection is going to be slow anyway surprised me therefore. But maybe it's fine as the typical use case is going to be small number of long running connections and traffic performance is going to make for the connection latency. Or there are other advantages, I don't know. But if that is the case, it would IMHO deserve to be explained. Michal Kubecek _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
