From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AD9FC43381 for ; Tue, 2 Apr 2019 07:37:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 60B2E2070D for ; Tue, 2 Apr 2019 07:37:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729205AbfDBHhM (ORCPT ); Tue, 2 Apr 2019 03:37:12 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:41315 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727021AbfDBHhL (ORCPT ); Tue, 2 Apr 2019 03:37:11 -0400 Received: by mail-wr1-f68.google.com with SMTP id r4so15215637wrq.8 for ; Tue, 02 Apr 2019 00:37:10 -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:content-transfer-encoding :in-reply-to:user-agent; bh=Ucp2YsFFQM7ljrmlj94bsWQLOgBwfltFyPQMWGez3UM=; b=ujJimOVb2ALaN8oSm5QlhGsdXCUbBZixIUH46HT6hnIxX9Hp/CdZhyP54UC4KbOnWU XG6Ev+EzNLlDSK5AU7/SP8tbSpRTsb6Oxs1pId8BWPrCCMyixe663Mrddj955MzHB9uW ss6nZbHaSxRU7efasb99Id/M950So+aWZDafLSi2Eytad9c8h4H4t9Zikf9wFQXteLB8 jpXJQieshKA7M85omd3DukVwAswlT/D8FiZwhhfAVhrMAoUjaJYZ9No++Rbb8CVBjY7p relWm+U5sTJvwsbcS2XN4ybkJcGVOjKstcjCyp/tn2RdwEc7oBa1YJ+6555Ug4nuhbG7 lvxA== X-Gm-Message-State: APjAAAVRJfF3sBt0Z6vPptg6Y9xnDJJfXMM2K2vU3PJn3TKYUt6DVLkw pjQXBP2zvJypEf/gzjzZ28jkdw== X-Google-Smtp-Source: APXvYqxEGQj6duU1xqxPiVIFK6qKvR2DhG8xp7S9pgELSJ0v0lDwSkyGSz/Cxu11YBGLgIbW3bKIbA== X-Received: by 2002:a5d:618b:: with SMTP id j11mr16551196wru.123.1554190629775; Tue, 02 Apr 2019 00:37:09 -0700 (PDT) Received: from steredhat (host40-210-static.34-79-b.business.telecomitalia.it. [79.34.210.40]) by smtp.gmail.com with ESMTPSA id x5sm9779331wrt.72.2019.04.02.00.37.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 00:37:09 -0700 (PDT) Date: Tue, 2 Apr 2019 09:37:06 +0200 From: Stefano Garzarella To: Alex =?utf-8?Q?Benn=C3=A9e?= Cc: qemu devel list , netdev@vger.kernel.org, Stefan Hajnoczi Subject: Re: VSOCK benchmark and optimizations Message-ID: <20190402073706.7t5w5gyj5tf7quwk@steredhat> References: <20190401163240.xw24ezsloy5ds2hz@steredhat> <87zhp9599u.fsf@zen.linaroharston> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87zhp9599u.fsf@zen.linaroharston> User-Agent: NeoMutt/20180716 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Apr 02, 2019 at 04:19:25AM +0000, Alex Bennée wrote: > > Stefano Garzarella writes: > > > Hi Alex, > > I'm sending you some benchmarks and information about VSOCK CCing qemu-devel > > and linux-netdev (maybe this info could be useful for others :)) > > > > One of the VSOCK advantages is the simple configuration: you don't need to set > > up IP addresses for guest/host, and it can be used with the standard POSIX > > socket API. [1] > > > > I'm currently working on it, so the "optimized" values are still work in > > progress and I'll send the patches upstream (Linux) as soon as possible. > > (I hope in 1 or 2 weeks) > > > > Optimizations: > > + reducing the number of credit update packets > > - RX side sent, on every packet received, an empty packet only to inform the > > TX side about the space in the RX buffer. > > + increase RX buffers size to 64 KB (from 4 KB) > > + merge packets to fill RX buffers > > > > As benchmark tool I used iperf3 [2] modified with VSOCK support: > > > > host -> guest [Gbps] guest -> host [Gbps] > > pkt_size before opt. optimized before opt. optimized > > 1K 0.5 1.6 1.4 1.4 > > 2K 1.1 3.1 2.3 2.5 > > 4K 2.0 5.6 4.2 4.4 > > 8K 3.2 10.2 7.2 7.5 > > 16K 6.4 14.2 9.4 11.3 > > 32K 9.8 18.9 9.2 17.8 > > 64K 13.8 22.9 8.8 25.0 > > 128K 17.6 24.5 7.7 25.7 > > 256K 19.0 24.8 8.1 25.6 > > 512K 20.8 25.1 8.1 25.4 > > > > > > How to reproduce: > > > > host$ modprobe vhost_vsock > > host$ qemu-system-x86_64 ... -device vhost-vsock-pci,guest-cid=3 > > # Note: Guest CID should be >= 3 > > # (0, 1 are reserved and 2 identify the host) > > > > guest$ iperf3 --vsock -s > > > > host$ iperf3 --vsock -c 3 -l ${pkt_size} # host -> guest > > host$ iperf3 --vsock -c 3 -l ${pkt_size} -R # guest -> host > > > > > > If you want, I can do a similar benchmark (with iperf3) using a networking > > card (do you have a specific configuration?). > > My main interest is how it stacks up against: > > --device virtio-net-pci and I guess the vhost equivalent I'll do some tests with virtio-net and vhost. > > AIUI one of the motivators was being able to run something like NFS for > a guest FS over vsock instead of the overhead from UDP and having to > deal with the additional complication of having a working network setup. > CCing Stefan. I know he is working on virtio-fs that maybe suite better with your use cases. He also worked on VSOCK support for NFS, but I think it is not merged upstream. Thanks, Stefano