search for: virtio_transport_set_buffer_size

...y_send_pre_block, > .notify_send_pre_enqueue = > virtio_transport_notify_send_pre_enqueue, > .notify_send_post_enqueue = > virtio_transport_notify_send_post_enqueue, > + .notify_buffer_size = virtio_transport_notify_buffer_size, > > - .set_buffer_size = virtio_transport_set_buffer_size, > - .set_min_buffer_size = > virtio_transport_set_min_buffer_size, > - .set_max_buffer_size = > virtio_transport_set_max_buffer_size, > - .get_buffer_size = virtio_transport_get_buffer_size, > - .get_min_buffer_size = > virtio_transport_get_min_buff...

..._block = virtio_transport_notify_send_pre_block, .notify_send_pre_enqueue = virtio_transport_notify_send_pre_enqueue, .notify_send_post_enqueue = virtio_transport_notify_send_post_enqueue, + .notify_buffer_size = virtio_transport_notify_buffer_size, - .set_buffer_size = virtio_transport_set_buffer_size, - .set_min_buffer_size = virtio_transport_set_min_buffer_size, - .set_max_buffer_size = virtio_transport_set_max_buffer_size, - .get_buffer_size = virtio_transport_get_buffer_size, - .get_min_buffer_size = virtio_transport_get_min_buffer_size, - .get_max_buffer_size...

...->buffer_size > VIRTIO_VSOCK_MAX_BUF_SIZE) > + vsk->buffer_size = VIRTIO_VSOCK_MAX_BUF_SIZE; Hmm...this could be outside the [min, max] range. I'm not sure how much it matters. Another issue is that this patch drops the VIRTIO_VSOCK_MAX_BUF_SIZE limit that used to be enforced by virtio_transport_set_buffer_size(). Now the limit is only applied at socket init time. If the buffer size is changed later then VIRTIO_VSOCK_MAX_BUF_SIZE can be exceeded. If that doesn't matter, why even bother with VIRTIO_VSOCK_MAX_BUF_SIZE here? -------------- next part -------------- A non-text attachment was scrubbed......

...->buffer_size > VIRTIO_VSOCK_MAX_BUF_SIZE) > + vsk->buffer_size = VIRTIO_VSOCK_MAX_BUF_SIZE; Hmm...this could be outside the [min, max] range. I'm not sure how much it matters. Another issue is that this patch drops the VIRTIO_VSOCK_MAX_BUF_SIZE limit that used to be enforced by virtio_transport_set_buffer_size(). Now the limit is only applied at socket init time. If the buffer size is changed later then VIRTIO_VSOCK_MAX_BUF_SIZE can be exceeded. If that doesn't matter, why even bother with VIRTIO_VSOCK_MAX_BUF_SIZE here? -------------- next part -------------- A non-text attachment was scrubbed......

..._block = virtio_transport_notify_send_pre_block, .notify_send_pre_enqueue = virtio_transport_notify_send_pre_enqueue, .notify_send_post_enqueue = virtio_transport_notify_send_post_enqueue, + .notify_buffer_size = virtio_transport_notify_buffer_size, - .set_buffer_size = virtio_transport_set_buffer_size, - .set_min_buffer_size = virtio_transport_set_min_buffer_size, - .set_max_buffer_size = virtio_transport_set_max_buffer_size, - .get_buffer_size = virtio_transport_get_buffer_size, - .get_min_buffer_size = virtio_transport_get_min_buffer_size, - .get_max_buffer_size...

...ck_bh(&vvs->rx_lock); pkt->hdr.fwd_cnt = cpu_to_le32(vvs->fwd_cnt); pkt->hdr.buf_alloc = cpu_to_le32(vvs->buf_alloc); - spin_unlock_bh(&vvs->tx_lock); + spin_unlock_bh(&vvs->rx_lock); } EXPORT_SYMBOL_GPL(virtio_transport_inc_tx_pkt); @@ -434,7 +434,9 @@ void virtio_transport_set_buffer_size(struct vsock_sock *vsk, u64 val) if (val > vvs->buf_size_max) vvs->buf_size_max = val; vvs->buf_size = val; + spin_lock_bh(&vvs->rx_lock); vvs->buf_alloc = val; + spin_unlock_bh(&vvs->rx_lock); } EXPORT_SYMBOL_GPL(virtio_transport_set_buffer_size); -- 2.20...

From: Stefano Garzarella <sgarzare at redhat.com> Date: Fri, 31 May 2019 15:39:51 +0200 > @@ -434,7 +434,9 @@ void virtio_transport_set_buffer_size(struct vsock_sock *vsk, u64 val) > if (val > vvs->buf_size_max) > vvs->buf_size_max = val; > vvs->buf_size = val; > + spin_lock_bh(&vvs->rx_lock); > vvs->buf_alloc = val; > + spin_unlock_bh(&vvs->rx_lock); This locking doesn't do anything...

...0, Stefano Garzarella wrote: > On Wed, Oct 09, 2019 at 01:30:26PM +0100, Stefan Hajnoczi wrote: > > On Fri, Sep 27, 2019 at 01:26:57PM +0200, Stefano Garzarella wrote: > > Another issue is that this patch drops the VIRTIO_VSOCK_MAX_BUF_SIZE > > limit that used to be enforced by virtio_transport_set_buffer_size(). > > Now the limit is only applied at socket init time. If the buffer size > > is changed later then VIRTIO_VSOCK_MAX_BUF_SIZE can be exceeded. If > > that doesn't matter, why even bother with VIRTIO_VSOCK_MAX_BUF_SIZE > > here? > > > > The .notify_buff...

This series makes the credit mechanism implemented in the virtio-vsock devices more robust. Patch 1 sends an update to the remote peer when the buf_alloc change. Patch 2 prevents a malicious peer (especially the guest) can consume all the memory of the other peer, discarding packets when the credit available is not respected. Stefano Garzarella (2): vsock/virtio: send a credit update when

...nit = virtio_transport_notify_send_init, + .notify_send_pre_block = virtio_transport_notify_send_pre_block, + .notify_send_pre_enqueue = virtio_transport_notify_send_pre_enqueue, + .notify_send_post_enqueue = virtio_transport_notify_send_post_enqueue, + + .set_buffer_size = virtio_transport_set_buffer_size, + .set_min_buffer_size = virtio_transport_set_min_buffer_size, + .set_max_buffer_size = virtio_transport_set_max_buffer_size, + .get_buffer_size = virtio_transport_get_buffer_size, + .get_min_buffer_size = virtio_transport_get_min_buffer_size, + .get_max_buffer_size...

This series tries to increase the throughput of virtio-vsock with slight changes. While I was testing the v2 of this series I discovered an huge use of memory, so I added patch 1 to mitigate this issue. I put it in this series in order to better track the performance trends. v3: - Patch 1: added a threshold to copy only small packets [Jason] - Patch 1: replaced the allocation of a new buffer

...fer_size is <= of the max, so since we are lowering it, the max should be respected. For the min you are right, but I think this limit is stricter than the min set by the user. > > Another issue is that this patch drops the VIRTIO_VSOCK_MAX_BUF_SIZE > limit that used to be enforced by virtio_transport_set_buffer_size(). > Now the limit is only applied at socket init time. If the buffer size > is changed later then VIRTIO_VSOCK_MAX_BUF_SIZE can be exceeded. If > that doesn't matter, why even bother with VIRTIO_VSOCK_MAX_BUF_SIZE > here? > The .notify_buffer_size() should avoid this issue,...

...t_do_socket_init(struct vsock_sock *vsk, > + struct vsock_sock *psk); > +u64 virtio_transport_get_buffer_size(struct vsock_sock *vsk); > +u64 virtio_transport_get_min_buffer_size(struct vsock_sock *vsk); > +u64 virtio_transport_get_max_buffer_size(struct vsock_sock *vsk); > +void virtio_transport_set_buffer_size(struct vsock_sock *vsk, u64 val); > +void virtio_transport_set_min_buffer_size(struct vsock_sock *vsk, u64 val); > +void virtio_transport_set_max_buffer_size(struct vsock_sock *vs, u64 val); > +int > +virtio_transport_notify_poll_in(struct vsock_sock *vsk, > + size_t target, >...

...t_do_socket_init(struct vsock_sock *vsk, > + struct vsock_sock *psk); > +u64 virtio_transport_get_buffer_size(struct vsock_sock *vsk); > +u64 virtio_transport_get_min_buffer_size(struct vsock_sock *vsk); > +u64 virtio_transport_get_max_buffer_size(struct vsock_sock *vsk); > +void virtio_transport_set_buffer_size(struct vsock_sock *vsk, u64 val); > +void virtio_transport_set_min_buffer_size(struct vsock_sock *vsk, u64 val); > +void virtio_transport_set_max_buffer_size(struct vsock_sock *vs, u64 val); > +int > +virtio_transport_notify_poll_in(struct vsock_sock *vsk, > + size_t target, >...

...); + +int virtio_transport_do_socket_init(struct vsock_sock *vsk, + struct vsock_sock *psk); +u64 virtio_transport_get_buffer_size(struct vsock_sock *vsk); +u64 virtio_transport_get_min_buffer_size(struct vsock_sock *vsk); +u64 virtio_transport_get_max_buffer_size(struct vsock_sock *vsk); +void virtio_transport_set_buffer_size(struct vsock_sock *vsk, u64 val); +void virtio_transport_set_min_buffer_size(struct vsock_sock *vsk, u64 val); +void virtio_transport_set_max_buffer_size(struct vsock_sock *vs, u64 val); +int +virtio_transport_notify_poll_in(struct vsock_sock *vsk, + size_t target, + bool *data_ready_now); +i...

...); + +int virtio_transport_do_socket_init(struct vsock_sock *vsk, + struct vsock_sock *psk); +u64 virtio_transport_get_buffer_size(struct vsock_sock *vsk); +u64 virtio_transport_get_min_buffer_size(struct vsock_sock *vsk); +u64 virtio_transport_get_max_buffer_size(struct vsock_sock *vsk); +void virtio_transport_set_buffer_size(struct vsock_sock *vsk, u64 val); +void virtio_transport_set_min_buffer_size(struct vsock_sock *vsk, u64 val); +void virtio_transport_set_max_buffer_size(struct vsock_sock *vs, u64 val); +int +virtio_transport_notify_poll_in(struct vsock_sock *vsk, + size_t target, + bool *data_ready_now); +i...

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware