search for: stream_enqueue

...39; to virtio-vsock device. > > > > Thanks, > > Stefano > > Why would a remote care about buffer sizes? > > Let's first see what the issues are. If they exist > we can either fix the bugs, or code the bug as a feature in spec. > The vhost_transport '.stream_enqueue' callback [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), passing the user message. This function allocates a new packet, copying the user message, but (before this series) it limits the packet size to the VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE (4K): static int virtio...

...39; to virtio-vsock device. > > > > Thanks, > > Stefano > > Why would a remote care about buffer sizes? > > Let's first see what the issues are. If they exist > we can either fix the bugs, or code the bug as a feature in spec. > The vhost_transport '.stream_enqueue' callback [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), passing the user message. This function allocates a new packet, copying the user message, but (before this series) it limits the packet size to the VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE (4K): static int virtio...

...ock.c:vhost_vsock_alloc_pkt()] So in this way we can limit the packets sent from the guest. 2. When the host send packets, it help us to increase the parallelism (especially if the guest has 64 KB RX buffers) because the user thread will split packets, calling multiple times transport->stream_enqueue() in net/vmw_vsock/af_vsock.c:vsock_stream_sendmsg() while the vhost_transport_send_pkt_work() send them to the guest. Do you think make sense? Thanks, Stefano

...ock.c:vhost_vsock_alloc_pkt()] So in this way we can limit the packets sent from the guest. 2. When the host send packets, it help us to increase the parallelism (especially if the guest has 64 KB RX buffers) because the user thread will split packets, calling multiple times transport->stream_enqueue() in net/vmw_vsock/af_vsock.c:vsock_stream_sendmsg() while the vhost_transport_send_pkt_work() send them to the guest. Do you think make sense? Thanks, Stefano

...> > > > > Why would a remote care about buffer sizes? > > > > > > Let's first see what the issues are. If they exist > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > The vhost_transport '.stream_enqueue' callback > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > passing the user message. This function allocates a new packet, copying > > the user message, but (before this series) it limits the packet size to > > the VIRTIO_VSOCK_DEFA...

...> > > > > Why would a remote care about buffer sizes? > > > > > > Let's first see what the issues are. If they exist > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > The vhost_transport '.stream_enqueue' callback > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > passing the user message. This function allocates a new packet, copying > > the user message, but (before this series) it limits the packet size to > > the VIRTIO_VSOCK_DEFA...

...er sizes? > > > > > > > > > > Let's first see what the issues are. If they exist > > > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > > > > > > > The vhost_transport '.stream_enqueue' callback > > > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > > > passing the user message. This function allocates a new packet, copying > > > > the user message, but (before this series) it limits the packet size to &...

...er sizes? > > > > > > > > > > Let's first see what the issues are. If they exist > > > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > > > > > > > The vhost_transport '.stream_enqueue' callback > > > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > > > passing the user message. This function allocates a new packet, copying > > > > the user message, but (before this series) it limits the packet size to &...

...= vhost_transport_cancel_pkt, + + .dgram_enqueue = virtio_transport_dgram_enqueue, + .dgram_dequeue = virtio_transport_dgram_dequeue, + .dgram_bind = virtio_transport_dgram_bind, + .dgram_allow = virtio_transport_dgram_allow, + + .stream_enqueue = virtio_transport_stream_enqueue, + .stream_dequeue = virtio_transport_stream_dequeue, + .stream_has_data = virtio_transport_stream_has_data, + .stream_has_space = virtio_transport_stream_has_space, + .stream_rcvhiwat = virtio_transport_stream_rcvh...

We are implementing a test suite for the VSOCK sockets and we discovered that vmci_transport never allowed half-closed socket on the host side. As Jorgen explained [1] this is due to the implementation of VMCI. Since we want to have the same behaviour across all transports, this series adds a section in the "Implementation notes" to exaplain this behaviour, and changes the

We are implementing a test suite for the VSOCK sockets and we discovered that vmci_transport never allowed half-closed socket on the host side. As Jorgen explained [1] this is due to the implementation of VMCI. Since we want to have the same behaviour across all transports, this series adds a section in the "Implementation notes" to exaplain this behaviour, and changes the

...*/ + if (vsk->peer_shutdown == SHUTDOWN_MASK) + return 0; + + return virtio_transport_stream_has_data(vsk); +} + /* Callers that dereference the return value must hold vhost_vsock_mutex or the * RCU read lock. */ @@ -804,7 +819,7 @@ static struct virtio_transport vhost_transport = { .stream_enqueue = virtio_transport_stream_enqueue, .stream_dequeue = virtio_transport_stream_dequeue, - .stream_has_data = virtio_transport_stream_has_data, + .stream_has_data = vhost_transport_stream_has_data, .stream_has_space = virtio_transport_stream_has_sp...

...gt; Thanks, > > > Stefano > > > > Why would a remote care about buffer sizes? > > > > Let's first see what the issues are. If they exist > > we can either fix the bugs, or code the bug as a feature in spec. > > > > The vhost_transport '.stream_enqueue' callback > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > passing the user message. This function allocates a new packet, copying > the user message, but (before this series) it limits the packet size to > the VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE (4K)...

Since now we are able to split packets, we can avoid limiting their sizes to VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE. Instead, we can use VIRTIO_VSOCK_MAX_PKT_BUF_SIZE as the max packet size. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- net/vmw_vsock/virtio_transport_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

...+ return 0; > + > + return virtio_transport_stream_has_data(vsk); > +} > + > /* Callers that dereference the return value must hold vhost_vsock_mutex or the > * RCU read lock. > */ > @@ -804,7 +819,7 @@ static struct virtio_transport vhost_transport = { > > .stream_enqueue = virtio_transport_stream_enqueue, > .stream_dequeue = virtio_transport_stream_dequeue, > - .stream_has_data = virtio_transport_stream_has_data, > + .stream_has_data = vhost_transport_stream_has_data, > .stream_has_space = virtio_tra...

...old vhost_vsock.ko. Therefore we should probably just leave the limit for now. > 2. When the host send packets, it help us to increase the parallelism > (especially if the guest has 64 KB RX buffers) because the user thread > will split packets, calling multiple times transport->stream_enqueue() > in net/vmw_vsock/af_vsock.c:vsock_stream_sendmsg() while the > vhost_transport_send_pkt_work() send them to the guest. Sorry, I don't understand the reasoning. Overall this creates more work. Are you saying the benefit is that vhost_transport_send_pkt_work() can run "ear...

...would a remote care about buffer sizes? > > > > > > > > Let's first see what the issues are. If they exist > > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > > > > The vhost_transport '.stream_enqueue' callback > > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > > passing the user message. This function allocates a new packet, copying > > > the user message, but (before this series) it limits the packet size to > > > t...

...> > > > > > > > Let's first see what the issues are. If they exist > > > > > > we can either fix the bugs, or code the bug as a feature in spec. > > > > > > > > > > > > > > > > The vhost_transport '.stream_enqueue' callback > > > > > [virtio_transport_stream_enqueue()] calls the virtio_transport_send_pkt_info(), > > > > > passing the user message. This function allocates a new packet, copying > > > > > the user message, but (before this series) it limits the p...

...the limit in order to be compatible with old vhost_vsock. > > > 2. When the host send packets, it help us to increase the parallelism > > (especially if the guest has 64 KB RX buffers) because the user thread > > will split packets, calling multiple times transport->stream_enqueue() > > in net/vmw_vsock/af_vsock.c:vsock_stream_sendmsg() while the > > vhost_transport_send_pkt_work() send them to the guest. > > Sorry, I don't understand the reasoning. Overall this creates more > work. Are you saying the benefit is that > vhost_transport_sen...

...the limit in order to be compatible with old vhost_vsock. > > > 2. When the host send packets, it help us to increase the parallelism > > (especially if the guest has 64 KB RX buffers) because the user thread > > will split packets, calling multiple times transport->stream_enqueue() > > in net/vmw_vsock/af_vsock.c:vsock_stream_sendmsg() while the > > vhost_transport_send_pkt_work() send them to the guest. > > Sorry, I don't understand the reasoning. Overall this creates more > work. Are you saying the benefit is that > vhost_transport_sen...