On Tue, Jul 27, 2021 at 12:34:36PM +0300, Arseny Krasnov wrote:
On 27.07.2021 10:59, Stefano Garzarella wrote:
Caution: This is an external email. Be cautious while opening links or attachments.
On Mon, Jul 26, 2021 at 07:31:33PM +0300, Arseny Krasnov wrote:
This patchset implements support of MSG_EOR bit for SEQPACKET
AF_VSOCK sockets over virtio transport.
Idea is to distinguish concepts of 'messages' and 'records'.
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.
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.
At this point it's probably better to rename the old flag, so we stay
compatible.
What happens if one of the two peers does not support MSG_EOR handling,
while the other does?
I'll do a closer review in the next few days.
Thank You, also i think MSG_EOR support must be described in spec
Yep, sure!
What do you think about the concerns above?
Stefano
