Message-ID: <47ce307b-f95e-25c7-ed58-9cd1cbff5b57@redhat.com>
Date:   Thu, 10 Jun 2021 15:46:55 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Stefano Garzarella <sgarzare@...hat.com>
Cc:     "Jiang Wang ." <jiang.wang@...edance.com>,
        virtualization@...ts.linux-foundation.org,
        Stefan Hajnoczi <stefanha@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Arseny Krasnov <arseny.krasnov@...persky.com>,
        jhansen@...are.comments, cong.wang@...edance.com,
        Xiongchun Duan <duanxiongchun@...edance.com>,
        Yongji Xie <xieyongji@...edance.com>,
        柴稳 <chaiwen.cc@...edance.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Colin Ian King <colin.king@...onical.com>,
        Jorgen Hansen <jhansen@...are.com>,
        Andra Paraschiv <andraprs@...zon.com>,
        Norbert Slusarek <nslusarek@....net>,
        Lu Wei <luwei32@...wei.com>,
        Alexander Popov <alex.popov@...ux.com>, kvm@...r.kernel.org,
        Networking <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC v1 0/6] virtio/vsock: introduce SOCK_DGRAM support


在 2021/6/10 下午3:23, Stefano Garzarella 写道:
> On Thu, Jun 10, 2021 at 12:02:35PM +0800, Jason Wang wrote:
>>
>> 在 2021/6/10 上午11:43, Jiang Wang . 写道:
>>> On Wed, Jun 9, 2021 at 6:51 PM Jason Wang <jasowang@...hat.com> wrote:
>>>>
>>>> 在 2021/6/10 上午7:24, Jiang Wang 写道:
>>>>> This patchset implements support of SOCK_DGRAM for virtio
>>>>> transport.
>>>>>
>>>>> Datagram sockets are connectionless and unreliable. To avoid 
>>>>> unfair contention
>>>>> with stream and other sockets, add two more virtqueues and
>>>>> a new feature bit to indicate if those two new queues exist or not.
>>>>>
>>>>> Dgram does not use the existing credit update mechanism for
>>>>> stream sockets. When sending from the guest/driver, sending packets
>>>>> synchronously, so the sender will get an error when the virtqueue 
>>>>> is full.
>>>>> When sending from the host/device, send packets asynchronously
>>>>> because the descriptor memory belongs to the corresponding QEMU
>>>>> process.
>>>>
>>>> What's the use case for the datagram vsock?
>>>>
>>> One use case is for non critical info logging from the guest
>>> to the host, such as the performance data of some applications.
>>
>>
>> Anything that prevents you from using the stream socket?
>>
>>
>>>
>>> It can also be used to replace UDP communications between
>>> the guest and the host.
>>
>>
>> Any advantage for VSOCK in this case? Is it for performance (I guess 
>> not since I don't exepct vsock will be faster).
>
> I think the general advantage to using vsock are for the guest agents 
> that potentially don't need any configuration.


Right, I wonder if we really need datagram consider the host to guest 
communication is reliable.

(Note that I don't object it since vsock has already supported that, 
just wonder its use cases)


>
>>
>> An obvious drawback is that it breaks the migration. Using UDP you 
>> can have a very rich features support from the kernel where vsock can't.
>>
>
> Thanks for bringing this up!
> What features does UDP support and datagram on vsock could not support?


E.g the sendpage() and busy polling. And using UDP means qdiscs and eBPF 
can work.


>
>>
>>>
>>>>> The virtio spec patch is here:
>>>>> https://www.spinics.net/lists/linux-virtualization/msg50027.html
>>>>
>>>> Have a quick glance, I suggest to split mergeable rx buffer into an
>>>> separate patch.
>>> Sure.
>>>
>>>> But I think it's time to revisit the idea of unifying the 
>>>> virtio-net and
>>>> virtio-vsock. Otherwise we're duplicating features and bugs.
>>> For mergeable rxbuf related code, I think a set of common helper
>>> functions can be used by both virtio-net and virtio-vsock. For other
>>> parts, that may not be very beneficial. I will think about more.
>>>
>>> If there is a previous email discussion about this topic, could you 
>>> send me
>>> some links? I did a quick web search but did not find any related
>>> info. Thanks.
>>
>>
>> We had a lot:
>>
>> [1] 
>> https://patchwork.kernel.org/project/kvm/patch/5BDFF537.3050806@huawei.com/
>> [2] 
>> https://lists.linuxfoundation.org/pipermail/virtualization/2018-November/039798.html
>> [3] https://www.lkml.org/lkml/2020/1/16/2043
>>
>
> When I tried it, the biggest problem that blocked me were all the 
> features strictly related to TCP/IP stack and ethernet devices that 
> vsock device doesn't know how to handle: TSO, GSO, checksums, MAC, 
> napi, xdp, min ethernet frame size, MTU, etc.


It depends on which level we want to share:

1) sharing codes
2) sharing devices
3) make vsock a protocol that is understood by the network core

We can start from 1), the low level tx/rx logic can be shared at both 
virtio-net and vhost-net. For 2) we probably need some work on the spec, 
probably with a new feature bit to demonstrate that it's a vsock device 
not a ethernet device. Then if it is probed as a vsock device we won't 
let packet to be delivered in the TCP/IP stack. For 3), it would be even 
harder and I'm not sure it's worth to do that.


>
> So in my opinion to unify them is not so simple, because vsock is not 
> really an ethernet device, but simply a socket.


We can start from sharing codes.


>
> But I fully agree that we shouldn't duplicate functionality and code, 
> so maybe we could find those common parts and create helpers to be 
> used by both.


Yes.

Thanks


>
> Thanks,
> Stefano
>

Powered by blists - more mailing lists