kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	virtualization@lists.linux-foundation.org,
	Jason Wang <jasowang@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [PATCH v4 1/5] vsock/virtio: limit the memory used per-socket
Date: Fri, 30 Aug 2019 11:40:59 +0200	[thread overview]
Message-ID: <20190830094059.c7qo5cxrp2nkrncd@steredhat> (raw)
In-Reply-To: <20190729095956-mutt-send-email-mst@kernel.org>

On Mon, Jul 29, 2019 at 10:04:29AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 17, 2019 at 01:30:26PM +0200, Stefano Garzarella wrote:
> > Since virtio-vsock was introduced, the buffers filled by the host
> > and pushed to the guest using the vring, are directly queued in
> > a per-socket list. These buffers are preallocated by the guest
> > with a fixed size (4 KB).
> > 
> > The maximum amount of memory used by each socket should be
> > controlled by the credit mechanism.
> > The default credit available per-socket is 256 KB, but if we use
> > only 1 byte per packet, the guest can queue up to 262144 of 4 KB
> > buffers, using up to 1 GB of memory per-socket. In addition, the
> > guest will continue to fill the vring with new 4 KB free buffers
> > to avoid starvation of other sockets.
> > 
> > This patch mitigates this issue copying the payload of small
> > packets (< 128 bytes) into the buffer of last packet queued, in
> > order to avoid wasting memory.
> > 
> > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> > Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> 
> This is good enough for net-next, but for net I think we
> should figure out how to address the issue completely.
> Can we make the accounting precise? What happens to
> performance if we do?
> 

Since I'm back from holidays, I'm restarting this thread to figure out
how to address the issue completely.

I did a better analysis of the credit mechanism that we implemented in
virtio-vsock to get a clearer view and I'd share it with you:

    This issue affect only the "host->guest" path. In this case, when the
    host wants to send a packet to the guest, it uses a "free" buffer
    allocated by the guest (4KB).
    The "free" buffers available for the host are shared between all
    sockets, instead, the credit mechanism is per-socket, I think to
    avoid the starvation of others sockets.
    The guests re-fill the "free" queue when the available buffers are
    less than half.

    Each peer have these variables in the per-socket state:
       /* local vars */
       buf_alloc        /* max bytes usable by this socket
                           [exposed to the other peer] */
       fwd_cnt          /* increased when RX packet is consumed by the
                           user space [exposed to the other peer] */
       tx_cnt 	        /* increased when TX packet is sent to the other peer */

       /* remote vars  */
       peer_buf_alloc   /* peer's buf_alloc */
       peer_fwd_cnt     /* peer's fwd_cnt */

    When a peer sends a packet, it increases the 'tx_cnt'; when the
    receiver consumes the packet (copy it to the user-space buffer), it
    increases the 'fwd_cnt'.
    Note: increments are made considering the payload length and not the
    buffer length.

    The value of 'buf_alloc' and 'fwd_cnt' are sent to the other peer in
    all packet headers or with an explicit CREDIT_UPDATE packet.

    The local 'buf_alloc' value can be modified by the user space using
    setsockopt() with optname=SO_VM_SOCKETS_BUFFER_SIZE.

    Before to send a packet, the peer checks the space available:
    	credit_available = peer_buf_alloc - (tx_cnt - peer_fwd_cnt)
    and it will send up to credit_available bytes to the other peer.

Possible solutions considering Michael's advice:
1. Use the buffer length instead of the payload length when we increment
   the counters:
  - This approach will account precisely the memory used per socket.
  - This requires changes in both guest and host.
  - It is not compatible with old drivers, so a feature should be negotiated.

2. Decrease the advertised 'buf_alloc' taking count of bytes queued in
   the socket queue but not used. (e.g. 256 byte used on 4K available in
   the buffer)
  - pkt->hdr.buf_alloc = buf_alloc - bytes_not_used.
  - This should be compatible also with old drivers.

Maybe the second is less invasive, but will it be too tricky?
Any other advice or suggestions?

Thanks in advance,
Stefano

  parent reply	other threads:[~2019-08-30  9:41 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17 11:30 [PATCH v4 0/5] vsock/virtio: optimizations to increase the throughput Stefano Garzarella
2019-07-17 11:30 ` [PATCH v4 1/5] vsock/virtio: limit the memory used per-socket Stefano Garzarella
2019-07-29 14:04   ` Michael S. Tsirkin
2019-07-29 15:36     ` Stefano Garzarella
2019-07-29 15:49       ` Michael S. Tsirkin
2019-07-29 16:19         ` Stefano Garzarella
2019-07-29 16:50           ` Stefano Garzarella
2019-07-29 19:10             ` Michael S. Tsirkin
2019-07-30  9:35               ` Stefano Garzarella
2019-07-30 20:42                 ` Michael S. Tsirkin
2019-08-01 10:47                   ` Stefano Garzarella
2019-08-01 13:21                     ` Michael S. Tsirkin
2019-08-01 13:36                       ` Stefano Garzarella
2019-09-01  8:26                         ` Michael S. Tsirkin
2019-09-01 10:17                           ` Michael S. Tsirkin
2019-09-02  9:57                             ` Stefano Garzarella
2019-09-02 15:23                               ` Michael S. Tsirkin
2019-09-03  4:39                               ` Michael S. Tsirkin
2019-09-03  7:45                                 ` Stefano Garzarella
2019-09-03  7:52                                   ` Michael S. Tsirkin
2019-09-03  8:00                                     ` Stefano Garzarella
2019-07-29 16:01       ` Michael S. Tsirkin
2019-07-29 16:41         ` Stefano Garzarella
2019-07-29 19:33           ` Michael S. Tsirkin
2019-08-30  9:40     ` Stefano Garzarella [this message]
2019-09-01  6:56       ` Michael S. Tsirkin
2019-09-02  8:39         ` Stefan Hajnoczi
2019-09-02  8:55           ` Stefano Garzarella
2019-10-11 13:40         ` Stefano Garzarella
2019-10-11 14:11           ` Michael S. Tsirkin
2019-10-11 14:23             ` Stefano Garzarella
2019-10-14  8:17           ` Stefan Hajnoczi
2019-10-14  8:21             ` Jason Wang
2019-10-14  8:38               ` Stefano Garzarella
2019-07-17 11:30 ` [PATCH v4 2/5] vsock/virtio: reduce credit update messages Stefano Garzarella
2019-07-22  8:36   ` Stefan Hajnoczi
2019-09-03  4:38   ` Michael S. Tsirkin
2019-09-03  7:31     ` Stefano Garzarella
2019-09-03  7:38       ` Michael S. Tsirkin
2019-07-17 11:30 ` [PATCH v4 3/5] vsock/virtio: fix locking in virtio_transport_inc_tx_pkt() Stefano Garzarella
2019-07-17 14:51   ` Michael S. Tsirkin
2019-07-18  7:43     ` Stefano Garzarella
2019-07-22  8:53   ` Stefan Hajnoczi
2019-07-17 11:30 ` [PATCH v4 4/5] vhost/vsock: split packets to send using multiple buffers Stefano Garzarella
2019-07-17 14:54   ` Michael S. Tsirkin
2019-07-18  7:50     ` Stefano Garzarella
2019-07-18  8:13       ` Michael S. Tsirkin
2019-07-18  9:37         ` Stefano Garzarella
2019-07-18 11:35           ` Michael S. Tsirkin
2019-07-19  8:08             ` Stefano Garzarella
2019-07-19  8:21               ` Jason Wang
2019-07-19  8:39                 ` Stefano Garzarella
2019-07-19  8:51                   ` Jason Wang
2019-07-19  9:20                     ` Stefano Garzarella
2019-07-22  9:06   ` Stefan Hajnoczi
2019-07-17 11:30 ` [PATCH v4 5/5] vsock/virtio: change the maximum packet size allowed Stefano Garzarella
2019-07-17 14:59   ` Michael S. Tsirkin
2019-07-18  7:52     ` Stefano Garzarella
2019-07-18 12:33       ` Michael S. Tsirkin
2019-07-19  8:29         ` Stefano Garzarella
2019-07-22  9:07   ` Stefan Hajnoczi
2019-07-22  9:08 ` [PATCH v4 0/5] vsock/virtio: optimizations to increase the throughput Stefan Hajnoczi
2019-07-22  9:14   ` Stefano Garzarella
2019-07-29 13:12     ` Stefan Hajnoczi
2019-07-29 13:59 ` Michael S. Tsirkin
2019-07-30  9:40   ` Stefano Garzarella
2019-07-30 10:03     ` Jason Wang
2019-07-30 15:38       ` Stefano Garzarella
2019-09-03  8:02 ` request for stable (was Re: [PATCH v4 0/5] vsock/virtio: optimizations to increase the throughput) Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190830094059.c7qo5cxrp2nkrncd@steredhat \
    --to=sgarzare@redhat.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).