Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3615379ybi; Mon, 29 Jul 2019 09:31:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqxs7DIB/1ncS9hlUrxUYLd2PDa9e2rCKyvyrXUiVVrTwoiu8VQ4Dg7v0m9Qd4yiqx0tuEc4 X-Received: by 2002:a63:121b:: with SMTP id h27mr89854619pgl.335.1564417886314; Mon, 29 Jul 2019 09:31:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564417886; cv=none; d=google.com; s=arc-20160816; b=p4+HZcR0UWY2g8a5yIG1P+aykNwLgZzR4z5nCvsrnTUNqqbLfPocsZmbfYgnVuAFpG D8Z9UTOeRGTFRhA7Rj22H5FRlMHFOoMOUBYyzskLKRsOx/Eq2iu0WEIf7O9R/hYn7U1I Tv+CZmQ6fPv3x5xHDhgXcOvqUoelE0aDoJUWXQRymHOHD5MmKOOFZTYfN1gdE6fDKmWB Lht4SZ0v5zDq3OV5Y4Va6ZHYnJplswkJWKieiK+jkrzoOp+m6GWNePILaVWr0BXwt26i UngmxOmLxEpb6nxYHrYIjmFK/YxFWTw8GJOIiy8soS7AkeWoTyr9AnZiH7Ze4pxYfcaT 0r7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=kbdqHLDZjC9a+s2gzn3LKNYZtrgZuml85rJixr3NhMA=; b=jCZHstgsqHeGZ4XPPtbHWymES4VFybBZiNt5bu+CKM1MTfBozIzST6mSwyAiAbqaJi wJM4aJsVSEp+/dPYx7Dp1MxTCAp7gQEHLunbrkfgBeEKdCjn+AaatkgyncZiYCtQqyDr 1y+zaJBS9OrrD3fq1VMVl3znbZc6F1I5harS3UepS8ni9u8p6Qm62KkhBmmW6rfsloE+ VAPPIzksQf+yppTkR3S66cU8jsL9aQVK185Wa5/UlGwfmrdXNP9FeBqCp4XryKm0LaeJ FeLENY/7ET0ARdrvSULyiRvyYgIWGBDsGbGHh1QPFrv1gDVRbYP9z7CLXybhanQHySwX wGsQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 33si25124337plu.126.2019.07.29.09.31.09; Mon, 29 Jul 2019 09:31:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725864AbfG2PhC (ORCPT + 99 others); Mon, 29 Jul 2019 11:37:02 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:40256 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725945AbfG2PhB (ORCPT ); Mon, 29 Jul 2019 11:37:01 -0400 Received: by mail-wr1-f68.google.com with SMTP id r1so62357724wrl.7 for ; Mon, 29 Jul 2019 08:36:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kbdqHLDZjC9a+s2gzn3LKNYZtrgZuml85rJixr3NhMA=; b=WpEpoZQZZ9PDYpfnO7sTpeHWy1slYQ9JUt3NCK1aXFPqPAfgRIhMG17DK5BIbefwnZ XTJa2sVb5R7Q0QSQOIbgdnMLiE7s5EUcOvMb6SBm4BGKkp3GyOdpgHUQecn+OfJ69g6T D0oN4rXaoeIC95gRUmz8yb88OyoF2pVKAQYpf/99OOta6zR3GEQouuSLwEnucsGgfBcK 1+PD99+YrsOC3ADcaz6X29SK2AYmrRnEO0I3gpuzsmsq2USB30qW199VcdxJDokH87Xo z+uMixplN0sKEZbI4ddjIWG+6KT/utCJbfqDUHMQtpqtBclhBtz66aoef/LSBMdvCVQE LsEg== X-Gm-Message-State: APjAAAXJEeqwlcABode0wWNjnYHJLLIX13+KNpT5XCM684ddDEvb8llt Rj8DLDcNGPpl3HEJw/fXjxX2bQ== X-Received: by 2002:adf:e705:: with SMTP id c5mr73459454wrm.270.1564414619334; Mon, 29 Jul 2019 08:36:59 -0700 (PDT) Received: from steredhat (host122-201-dynamic.13-79-r.retail.telecomitalia.it. [79.13.201.122]) by smtp.gmail.com with ESMTPSA id p63sm13455498wmp.45.2019.07.29.08.36.58 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 29 Jul 2019 08:36:58 -0700 (PDT) Date: Mon, 29 Jul 2019 17:36:56 +0200 From: Stefano Garzarella To: "Michael S. Tsirkin" Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Stefan Hajnoczi , "David S. Miller" , virtualization@lists.linux-foundation.org, Jason Wang , kvm@vger.kernel.org Subject: Re: [PATCH v4 1/5] vsock/virtio: limit the memory used per-socket Message-ID: <20190729153656.zk4q4rob5oi6iq7l@steredhat> References: <20190717113030.163499-1-sgarzare@redhat.com> <20190717113030.163499-2-sgarzare@redhat.com> <20190729095956-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190729095956-mutt-send-email-mst@kernel.org> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.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 > > Signed-off-by: Stefano Garzarella > > 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? > In order to do more precise accounting maybe we can use the buffer size, instead of payload size when we update the credit available. In this way, the credit available for each socket will reflect the memory actually used. I should check better, because I'm not sure what happen if the peer sees 1KB of space available, then it sends 1KB of payload (using a 4KB buffer). The other option is to copy each packet in a new buffer like I did in the v2 [2], but this forces us to make a copy for each packet that does not fill the entire buffer, perhaps too expensive. [2] https://patchwork.kernel.org/patch/10938741/ Thanks, Stefano