| Message ID | 20210816085036.4173627-1-arseny.krasnov@kaspersky.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | virtio/vsock: introduce MSG_EOR flag for SEQPACKET | expand |
Hello, please ping :) On 16.08.2021 11:50, Arseny Krasnov wrote: > This patchset implements support of MSG_EOR bit for SEQPACKET > AF_VSOCK sockets over virtio transport. > First we need to define 'messages' and 'records' like this: > Message is result of sending calls: 'write()', 'send()', 'sendmsg()' > etc. It has fixed maximum length, and it bounds are visible using > return from receive calls: 'read()', 'recv()', 'recvmsg()' etc. > Current implementation based on message definition above. > Record has unlimited length, it consists of multiple message, > and bounds of record are visible via MSG_EOR flag returned from > 'recvmsg()' call. Sender passes MSG_EOR to sending system call and > receiver will see MSG_EOR when corresponding message will be processed. > Idea of patchset comes from POSIX: it says that SEQPACKET > supports record boundaries which are visible for receiver using > MSG_EOR bit. So, it looks like MSG_EOR is enough thing for SEQPACKET > and we don't need to maintain boundaries of corresponding send - > receive system calls. But, for 'sendXXX()' and 'recXXX()' POSIX says, > that all these calls operates with messages, e.g. 'sendXXX()' sends > message, while 'recXXX()' reads messages and for SEQPACKET, 'recXXX()' > must read one entire message from socket, dropping all out of size > bytes. Thus, both message boundaries and MSG_EOR bit must be supported > to follow POSIX rules. > To support MSG_EOR new bit was added along with existing > 'VIRTIO_VSOCK_SEQ_EOR': 'VIRTIO_VSOCK_SEQ_EOM'(end-of-message) - now it > works in the same way as 'VIRTIO_VSOCK_SEQ_EOR'. But 'VIRTIO_VSOCK_SEQ_EOR' > is used to mark 'MSG_EOR' bit passed from userspace. > This patchset includes simple test for MSG_EOR. > > Arseny Krasnov(6): > virtio/vsock: rename 'EOR' to 'EOM' bit. > virtio/vsock: add 'VIRTIO_VSOCK_SEQ_EOR' bit. > vhost/vsock: support MSG_EOR bit processing > virtio/vsock: support MSG_EOR bit processing > af_vsock: rename variables in receive loop > vsock_test: update message bounds test for MSG_EOR > > drivers/vhost/vsock.c | 22 +++++++++++++--------- > include/uapi/linux/virtio_vsock.h | 3 ++- > net/vmw_vsock/af_vsock.c | 10 +++++----- > net/vmw_vsock/virtio_transport_common.c | 23 +++++++++++++++-------- > tools/testing/vsock/vsock_test.c | 8 +++++++- > 5 files changed, 42 insertions(+), 24 deletions(-) > > v2 -> v3: > - 'virtio/vsock: rename 'EOR' to 'EOM' bit.' - commit message updated. > - 'VIRTIO_VSOCK_SEQ_EOR' bit add moved to separate patch. > - 'vhost/vsock: support MSG_EOR bit processing' - commit message > updated. > - 'vhost/vsock: support MSG_EOR bit processing' - removed unneeded > 'le32_to_cpu()', because input argument was already in CPU > endianness. > > v1 -> v2: > - 'VIRTIO_VSOCK_SEQ_EOR' is renamed to 'VIRTIO_VSOCK_SEQ_EOM', to > support backward compatibility. > - use bitmask of flags to restore in vhost.c, instead of separated > bool variable for each flag. > - test for EAGAIN removed, as logically it is not part of this > patchset(will be sent separately). > - cover letter updated(added part with POSIX description). > > Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com> >
Hi Arseny, On Mon, Aug 23, 2021 at 09:41:16PM +0300, Arseny Krasnov wrote: >Hello, please ping :) > Sorry, I was off last week. I left some minor comments in the patches. Let's wait a bit for other comments before next version, also on the spec, then I think you can send the next version without RFC tag. The target should be the net-next tree, since this is a new feature. Thanks, Stefano
On 24.08.2021 13:05, Stefano Garzarella wrote: > Caution: This is an external email. Be cautious while opening links or attachments. > > > > Hi Arseny, > > On Mon, Aug 23, 2021 at 09:41:16PM +0300, Arseny Krasnov wrote: >> Hello, please ping :) >> > Sorry, I was off last week. > I left some minor comments in the patches. > > Let's wait a bit for other comments before next version, also on the > spec, then I think you can send the next version without RFC tag. > The target should be the net-next tree, since this is a new feature. Hello, E.g. next version will be [net-next] instead of [RFC] for both kernel and spec patches? Thank You > > Thanks, > Stefano > >
On Tue, Aug 24, 2021 at 01:18:06PM +0300, Arseny Krasnov wrote: > >On 24.08.2021 13:05, Stefano Garzarella wrote: >> Caution: This is an external email. Be cautious while opening links or attachments. >> >> >> >> Hi Arseny, >> >> On Mon, Aug 23, 2021 at 09:41:16PM +0300, Arseny Krasnov wrote: >>> Hello, please ping :) >>> >> Sorry, I was off last week. >> I left some minor comments in the patches. >> >> Let's wait a bit for other comments before next version, also on the >> spec, then I think you can send the next version without RFC tag. >> The target should be the net-next tree, since this is a new feature. >Hello, > >E.g. next version will be [net-next] instead of [RFC] for both >kernel and spec patches? Nope, net-next tag is useful only for kernel patches (net tree - Documentation/networking/netdev-FAQ.rst). Thanks, Stefano
On 24.08.2021 13:31, Stefano Garzarella wrote: > Caution: This is an external email. Be cautious while opening links or attachments. > > > > On Tue, Aug 24, 2021 at 01:18:06PM +0300, Arseny Krasnov wrote: >> On 24.08.2021 13:05, Stefano Garzarella wrote: >>> Caution: This is an external email. Be cautious while opening links or attachments. >>> >>> >>> >>> Hi Arseny, >>> >>> On Mon, Aug 23, 2021 at 09:41:16PM +0300, Arseny Krasnov wrote: >>>> Hello, please ping :) >>>> >>> Sorry, I was off last week. >>> I left some minor comments in the patches. >>> >>> Let's wait a bit for other comments before next version, also on the >>> spec, then I think you can send the next version without RFC tag. >>> The target should be the net-next tree, since this is a new feature. >> Hello, >> >> E.g. next version will be [net-next] instead of [RFC] for both >> kernel and spec patches? > Nope, net-next tag is useful only for kernel patches (net tree - > Documentation/networking/netdev-FAQ.rst). Ack > > Thanks, > Stefano > >
On 24.08.2021 14:35, Arseny Krasnov wrote: > On 24.08.2021 13:31, Stefano Garzarella wrote: >> Caution: This is an external email. Be cautious while opening links or attachments. >> >> >> >> On Tue, Aug 24, 2021 at 01:18:06PM +0300, Arseny Krasnov wrote: >>> On 24.08.2021 13:05, Stefano Garzarella wrote: >>>> Caution: This is an external email. Be cautious while opening links or attachments. >>>> >>>> >>>> >>>> Hi Arseny, >>>> >>>> On Mon, Aug 23, 2021 at 09:41:16PM +0300, Arseny Krasnov wrote: >>>>> Hello, please ping :) >>>>> >>>> Sorry, I was off last week. >>>> I left some minor comments in the patches. >>>> >>>> Let's wait a bit for other comments before next version, also on the >>>> spec, then I think you can send the next version without RFC tag. >>>> The target should be the net-next tree, since this is a new feature. >>> Hello, >>> >>> E.g. next version will be [net-next] instead of [RFC] for both >>> kernel and spec patches? >> Nope, net-next tag is useful only for kernel patches (net tree - >> Documentation/networking/netdev-FAQ.rst). > Ack Hello, as there are no new comments on this week, i can send new patchsets for both kernel and spec today. Kernel patches will be with 'net-next' tag instead of RFC, spec patches will be without RFC tag. Thank You >> Thanks, >> Stefano >> >>
This patchset implements support of MSG_EOR bit for SEQPACKET AF_VSOCK sockets over virtio transport. First we need to define 'messages' and 'records' like this: Message is result of sending calls: 'write()', 'send()', 'sendmsg()' etc. It has fixed maximum length, and it bounds are visible using return from receive calls: 'read()', 'recv()', 'recvmsg()' etc. Current implementation based on message definition above. Record has unlimited length, it consists of multiple message, and bounds of record are visible via MSG_EOR flag returned from 'recvmsg()' call. Sender passes MSG_EOR to sending system call and receiver will see MSG_EOR when corresponding message will be processed. Idea of patchset comes from POSIX: it says that SEQPACKET supports record boundaries which are visible for receiver using MSG_EOR bit. So, it looks like MSG_EOR is enough thing for SEQPACKET and we don't need to maintain boundaries of corresponding send - receive system calls. But, for 'sendXXX()' and 'recXXX()' POSIX says, that all these calls operates with messages, e.g. 'sendXXX()' sends message, while 'recXXX()' reads messages and for SEQPACKET, 'recXXX()' must read one entire message from socket, dropping all out of size bytes. Thus, both message boundaries and MSG_EOR bit must be supported to follow POSIX rules. To support MSG_EOR new bit was added along with existing 'VIRTIO_VSOCK_SEQ_EOR': 'VIRTIO_VSOCK_SEQ_EOM'(end-of-message) - now it works in the same way as 'VIRTIO_VSOCK_SEQ_EOR'. But 'VIRTIO_VSOCK_SEQ_EOR' is used to mark 'MSG_EOR' bit passed from userspace. This patchset includes simple test for MSG_EOR. Arseny Krasnov(6): virtio/vsock: rename 'EOR' to 'EOM' bit. virtio/vsock: add 'VIRTIO_VSOCK_SEQ_EOR' bit. vhost/vsock: support MSG_EOR bit processing virtio/vsock: support MSG_EOR bit processing af_vsock: rename variables in receive loop vsock_test: update message bounds test for MSG_EOR drivers/vhost/vsock.c | 22 +++++++++++++--------- include/uapi/linux/virtio_vsock.h | 3 ++- net/vmw_vsock/af_vsock.c | 10 +++++----- net/vmw_vsock/virtio_transport_common.c | 23 +++++++++++++++-------- tools/testing/vsock/vsock_test.c | 8 +++++++- 5 files changed, 42 insertions(+), 24 deletions(-) v2 -> v3: - 'virtio/vsock: rename 'EOR' to 'EOM' bit.' - commit message updated. - 'VIRTIO_VSOCK_SEQ_EOR' bit add moved to separate patch. - 'vhost/vsock: support MSG_EOR bit processing' - commit message updated. - 'vhost/vsock: support MSG_EOR bit processing' - removed unneeded 'le32_to_cpu()', because input argument was already in CPU endianness. v1 -> v2: - 'VIRTIO_VSOCK_SEQ_EOR' is renamed to 'VIRTIO_VSOCK_SEQ_EOM', to support backward compatibility. - use bitmask of flags to restore in vhost.c, instead of separated bool variable for each flag. - test for EAGAIN removed, as logically it is not part of this patchset(will be sent separately). - cover letter updated(added part with POSIX description). Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>