On 2018/12/4 12:08, Michael S. Tsirkin wrote:

On Tue, Dec 04, 2018 at 10:21:40AM +0800, jiangyiwen wrote:

quoted

On 2018/12/4 9:31, Michael S. Tsirkin wrote:

quoted

On Mon, Dec 03, 2018 at 11:10:58AM +0800, jiangyiwen wrote:

quoted

On 2018/11/30 21:40, Michael S. Tsirkin wrote:

quoted

On Fri, Nov 30, 2018 at 09:10:03PM +0800, Jason Wang wrote:

quoted

On 2018/11/30 下午8:55, Jason Wang wrote:

quoted

On 2018/11/30 下午8:52, Michael S. Tsirkin wrote:

quoted

quoted

quoted

   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

Is your question why is virtio-vsock used instead of TCP on top of IP
on top of virtio-net?

No, my question is why not do vsock through virtio-net.

Thanks

Just to clarify, it's not about vosck over ethernet, and it's not about
inventing new features or APIs. It's probably something like:

- Let virtio-net driver probe vsock device and do vosck specific things if
needed to share as much codes.

- A new kind of sockfd (which is vsock based) for vhost-net for it to do
vsock specific things (hopefully it can be transparent).

The change should be totally transparent to userspace applications.

Thanks

Which code is duplicated between virtio vsock and virtio net right now?

Hi Michael,

AFAIK, there is almost no duplicate code between virtio vsock and virtio net now.

But, if virtio vsock wants to support mergeable rx buffer and multiqueue feature,
it has some duplicate codes from virtio net. Based on it, we both think vsock
may use virtio net as a transport channel, in this way, vsock can use some of
virtio net great features.

Thanks,
Yiwen.

What I would do is just copy some code and show a performance
benefit. If that works out it will be clearer which code
should be shared.

Hi Michael,

I have already sent a series of patches (VSOCK: support mergeable rx buffer in vhost-vsock)
a month ago, and the performance as follows:

I write a tool to test the vhost-vsock performance, mainly send big
packet(64K) included guest->Host and Host->Guest. The result as
follows:

Before performance:
              Single socket            Multiple sockets(Max Bandwidth)
Guest->Host   ~400MB/s                 ~480MB/s
Host->Guest   ~1450MB/s                ~1600MB/s

After performance:
              Single socket            Multiple sockets(Max Bandwidth)
Guest->Host   ~1700MB/s                ~2900MB/s
Host->Guest   ~1700MB/s                ~2900MB/s

quoted

From the test results, the performance is improved obviously, and guest

memory will not be wasted.

Oh I didn't see that one. Pls CC me in the future.

Looking at it I agree zero page allocation looks like an issue
but besides that, I think we can merge something similar
and look at refactoring and future extensions later.

However, any interface change (e.g. a new feature) must be CC'd to one of
virtio lists (subscriber-only).

Okay, previously I send Virtio-vsock patch only CC stefan and mailing lists
based on MAINTAINERS, because it only be related to Virtio-vsock.

Then, first I send v2 patch based on Jason's suggestions, and then let's
see how to combine with virtio-vsock and virtio-net. What do you think?

Thanks,
Yiwen.

quoted

In addition, multiqueue feature I have not implemented it yet.

Thanks,
Yiwen.

.

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization