On Thu, Nov 15, 2018 at 04:24:38PM +0800, Jason Wang wrote:

On 2018/11/15 下午3:04, Michael S. Tsirkin wrote:

quoted

On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:

quoted

Hi Stefan, Michael, Jason and everyone,

Several days ago, I discussed with jason about "Vsock over Virtio-net".
This idea has two advantages:
First, it can use many great features of virtio-net, like batching,
mergeable rx buffer and multiqueue, etc.
Second, it can reduce many duplicate codes and make it easy to be
maintained.

I'm not sure I get the motivation. Which features of
virtio net are relevant to vsock?

Vsock is just a L2 (and above) protocol from the view of the device.

I don't believe so. I think virtio-vsock operates at a transport level.
There is in theory a bit of network level but we don't really implement
it as it's only host to guest.  I am not aware of any data link
functionality n virtio-vsock. virtio-vsock provides services such as
connection-oriented communication, reliability, flow control and
multiplexing.

So I
think we should answer the question why we need two different paths for
networking traffic? Or what is the fundamental reason that makes vsock does
not go for virtio-net?

So virtio-vsock ensures reliability. If you want to compare it with
something that would be TCP or QUIC.  The fundamental difference between
virtio-vsock and e.g. TCP is that TCP operates in a packet loss environment.
So they are using timers for reliability, and receiver is always free to
discard any unacked data.

I agree they could be different type of devices but codes could be shared in
both guest and host (or even qemu) for not duplicating features(bugs).

Thanks

quoted

The ones that you mention
all seem to be mostly of use to the networking stack.