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
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
