On 27.07.2021 12:58, Stefano Garzarella wrote:
Caution: This is an external email. Be cautious while opening links or attachments.
On Tue, Jul 27, 2021 at 12:34:36PM +0300, Arseny Krasnov wrote:
quoted
On 27.07.2021 10:59, Stefano Garzarella wrote:
quoted
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:
quoted
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?
I think you are right, i'll rename EOR -> EOM, and EOR will be added by patch
Stefano