Re: [RFC PATCH v4 00/17] virtio/vsock: introduce SOCK_SEQPACKET support
From: Arseny Krasnov <hidden>
Date: 2021-02-12 06:12:58
Also in:
kvm, lkml
On 11.02.2021 17:57, Stefano Garzarella wrote:
Hi Arseny, On Mon, Feb 08, 2021 at 09:32:59AM +0300, Arseny Krasnov wrote:quoted
On 07.02.2021 19:20, Michael S. Tsirkin wrote:quoted
On Sun, Feb 07, 2021 at 06:12:56PM +0300, Arseny Krasnov wrote:quoted
This patchset impelements support of SOCK_SEQPACKET for virtio transport. As SOCK_SEQPACKET guarantees to save record boundaries, so to do it, two new packet operations were added: first for start of record and second to mark end of record(SEQ_BEGIN and SEQ_END later). Also, both operations carries metadata - to maintain boundaries and payload integrity. Metadata is introduced by adding special header with two fields - message count and message length: struct virtio_vsock_seq_hdr { __le32 msg_cnt; __le32 msg_len; } __attribute__((packed)); This header is transmitted as payload of SEQ_BEGIN and SEQ_END packets(buffer of second virtio descriptor in chain) in the same way as data transmitted in RW packets. Payload was chosen as buffer for this header to avoid touching first virtio buffer which carries header of packet, because someone could check that size of this buffer is equal to size of packet header. To send record, packet with start marker is sent first(it's header contains length of record and counter), then counter is incremented and all data is sent as usual 'RW' packets and finally SEQ_END is sent(it also carries counter of message, which is counter of SEQ_BEGIN + 1), also after sedning SEQ_END counter is incremented again. On receiver's side, length of record is known from packet with start record marker. To check that no packets were dropped by transport, counters of two sequential SEQ_BEGIN and SEQ_END are checked(counter of SEQ_END must be bigger that counter of SEQ_BEGIN by 1) and length of data between two markers is compared to length in SEQ_BEGIN header. Now as packets of one socket are not reordered neither on vsock nor on vhost transport layers, such markers allows to restore original record on receiver's side. If user's buffer is smaller that record length, when all out of size data is dropped. Maximum length of datagram is not limited as in stream socket, because same credit logic is used. Difference with stream socket is that user is not woken up until whole record is received or error occurred. Implementation also supports 'MSG_EOR' and 'MSG_TRUNC' flags. Tests also implemented. Arseny Krasnov (17): af_vsock: update functions for connectible socket af_vsock: separate wait data loop af_vsock: separate receive data loop af_vsock: implement SEQPACKET receive loop af_vsock: separate wait space loop af_vsock: implement send logic for SEQPACKET af_vsock: rest of SEQPACKET support af_vsock: update comments for stream sockets virtio/vsock: dequeue callback for SOCK_SEQPACKET virtio/vsock: fetch length for SEQPACKET record virtio/vsock: add SEQPACKET receive logic virtio/vsock: rest of SOCK_SEQPACKET support virtio/vsock: setup SEQPACKET ops for transport vhost/vsock: setup SEQPACKET ops for transport vsock_test: add SOCK_SEQPACKET tests loopback/vsock: setup SEQPACKET ops for transport virtio/vsock: simplify credit update function API drivers/vhost/vsock.c | 8 +- include/linux/virtio_vsock.h | 15 + include/net/af_vsock.h | 9 + include/uapi/linux/virtio_vsock.h | 16 + net/vmw_vsock/af_vsock.c | 588 +++++++++++++++------- net/vmw_vsock/virtio_transport.c | 5 + net/vmw_vsock/virtio_transport_common.c | 316 ++++++++++-- net/vmw_vsock/vsock_loopback.c | 5 + tools/testing/vsock/util.c | 32 +- tools/testing/vsock/util.h | 3 + tools/testing/vsock/vsock_test.c | 126 +++++ 11 files changed, 895 insertions(+), 228 deletions(-) TODO: - What to do, when server doesn't support SOCK_SEQPACKET. In current implementation RST is replied in the same way when listening port is not found. I think that current RST is enough,because case when server doesn't support SEQ_PACKET is same when listener missed(e.g. no listener in both cases).I think is fine.quoted
quoted
- virtio spec patchOkYes, please prepare a patch to discuss the VIRTIO spec changes. For example for 'virtio_vsock_seq_hdr', I left a comment about 'msg_cnt' naming that should be better to discuss with virtio guys.
Ok, i'll prepare it in v5. So I have to send it both LKML(as one of patches) and virtio mailing lists? (e.g. virtio-comment@lists.oasis-open.org)
Anyway, I reviewed this series and I left some comments. I think we are in a good shape :-)
Great, thanks for review. I'll consider all review comments in next version.
Thanks, Stefano