Re: [PATCH v11 00/18] virtio/vsock: introduce SOCK_SEQPACKET support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 11, 2021 at 05:39:01PM +0300, Arseny Krasnov wrote:

On 11.06.2021 15:25, Stefano Garzarella wrote:
Hi Arseny,

On Fri, Jun 11, 2021 at 02:17:00PM +0300, Arseny Krasnov wrote:
On 11.06.2021 14:07, Arseny Krasnov wrote:
	This patchset implements support of SOCK_SEQPACKET for virtio
transport.
	As SOCK_SEQPACKET guarantees to save record boundaries, so to
do it, new bit for field 'flags' was added: SEQ_EOR. This bit is
set to 1 in last RW packet of message.
	Now as  packets of one socket are not reordered neither on vsock
nor on vhost transport layers, such bit allows to restore original
message on receiver's side. If user's buffer is smaller than message
length, when all out of size data is dropped.
	Maximum length of datagram is limited by 'peer_buf_alloc' value.
	Implementation also supports 'MSG_TRUNC' flags.
	Tests also implemented.

	Thanks to stsp2@xxxxxxxxx for encouragements and initial design
recommendations.

 Arseny Krasnov (18):
  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: implement send logic for SEQPACKET
  af_vsock: rest of SEQPACKET support
  af_vsock: update comments for stream sockets
  virtio/vsock: set packet's type in virtio_transport_send_pkt_info()
  virtio/vsock: simplify credit update function API
  virtio/vsock: defines and constants for SEQPACKET
  virtio/vsock: dequeue callback for SOCK_SEQPACKET
  virtio/vsock: add SEQPACKET receive logic
  virtio/vsock: rest of SOCK_SEQPACKET support
  virtio/vsock: enable SEQPACKET for transport
  vhost/vsock: enable SEQPACKET for transport
  vsock/loopback: enable SEQPACKET for transport
  vsock_test: add SOCK_SEQPACKET tests
  virtio/vsock: update trace event for SEQPACKET

 drivers/vhost/vsock.c                              |  56 ++-
 include/linux/virtio_vsock.h                       |  10 +
 include/net/af_vsock.h                             |   8 +
 .../trace/events/vsock_virtio_transport_common.h   |   5 +-
 include/uapi/linux/virtio_vsock.h                  |   9 +
 net/vmw_vsock/af_vsock.c                           | 464 ++++++++++++------
 net/vmw_vsock/virtio_transport.c                   |  26 ++
 net/vmw_vsock/virtio_transport_common.c            | 179 +++++++-
 net/vmw_vsock/vsock_loopback.c                     |  12 +
 tools/testing/vsock/util.c                         |  32 +-
 tools/testing/vsock/util.h                         |   3 +
 tools/testing/vsock/vsock_test.c                   | 116 ++++++
 12 files changed, 730 insertions(+), 190 deletions(-)

 v10 -> v11:
 General changelog:
  - now data is copied to user's buffer only when
    whole message is received.
  - reader is woken up when EOR packet is received.
  - if read syscall was interrupted by signal or
    timeout, error is returned(not 0).

 Per patch changelog:
  see every patch after '---' line.
So here is new version for review with updates discussed earlier :)
Thanks, I'll review next week, but I suggest you again to split in two
series, since patchwork (and netdev maintainers) are not happy with a
series of 18 patches.

If you still prefer to keep them together during development, then
please use the RFC tag.

Also did you take a look at the FAQ for netdev that I linked last time?
I don't see the net-next tag...

I didn't use next tag because two patches from first seven(which was

considered to be sent to netdev) - 0004 and 0006

were changed in this patchset(because of last ideas about queueing

whole message). So i removed R-b line and now there is no sense to

use net-next tag for first patches. When it will be R-b - i'll send it

Okay, in that case better to use RFC tag.

to

netdev with such tag and we can continue discussing second part

of patches(virtio specific).

Don't worry for now. You can do it for the next round, but I think all the patches will go through netdev and would be better to split in 2 series, both of them with net-next tag.

Thanks,
Stefano

_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization



[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux