On 2018/11/29 下午10:00, Michael S. Tsirkin wrote:
On Thu, Nov 15, 2018 at 04:24:38PM +0800, Jason Wang wrote:
On 2018/11/15 下午3:04, Michael S. Tsirkin wrote:
On Thu, Nov 15, 2018 at 11:56:03AM +0800, jiangyiwen wrote:
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.
Ok, consider it doesn't implement L2, it's pretty fit for virtio-net I
believe?
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.
It's done at the level of protocol instead of virtio transport or virtio
device.
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.
Virtio-net knows nothing above L2, so they are totally transparent to
device itself. I still don't get why not using virtio-net instead.
Thanks
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
The ones that you mention
all seem to be mostly of use to the networking stack.
