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=unavailable 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 661FBC4360F for ; Fri, 5 Apr 2019 07:49:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3852D217D7 for ; Fri, 5 Apr 2019 07:49:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729861AbfDEHtW (ORCPT ); Fri, 5 Apr 2019 03:49:22 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:40117 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730024AbfDEHtW (ORCPT ); Fri, 5 Apr 2019 03:49:22 -0400 Received: by mail-wr1-f68.google.com with SMTP id h4so6776620wre.7 for ; Fri, 05 Apr 2019 00:49:21 -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=U8q/dV+jUyLM8P4IzxbEg7fTh9kBuUuI18cx/4ZklsM=; b=tJjjHb+lV3KM+RDVrOUQbaRS+43Ct18cX7LGsmyjkOobL+zXph/v0XzRBW749hkJWJ VsJCqqtpzGWoKin03t3zHd3bI2wBZ4ebUv5wMxkZnkOL38IOUxnj+TI8CSmCIomzdTIM 5rO5hzAwhdfQoHoE0LhX5/NH9P0rchL6hy0KuTPbDPD2csPy2rvpya0WVT5cPNtaaymm J1hkCzStqDarFS916ejTuaLcOjkYFvedy+6pDdScH6wWy54wS1gumQR6MVBA0qoSAxr4 Y6KZLwo2JJIEJy4kXi8aMTGB9NprcsNLmu7LiW8WfOFjEx1L/JhvVOw+3j5lzz3C+cKi aLfA== X-Gm-Message-State: APjAAAUPpEx9MHpyxrYiJz2YDkBpDNhCwb3CqjRJfCCVumLv1b3eRQIS CgpNb2I9WcJxtlcD6Yvu3PLZtQ== X-Google-Smtp-Source: APXvYqyqeoNmMQ7J44y2LQjEeu6SgtcE8ycj3r91YErfV/9hNc17FDEY2Zios7sL8s1ylZy+pfKLew== X-Received: by 2002:a5d:68cf:: with SMTP id p15mr7107520wrw.301.1554450560539; Fri, 05 Apr 2019 00:49:20 -0700 (PDT) Received: from steredhat (host35-203-static.12-87-b.business.telecomitalia.it. [87.12.203.35]) by smtp.gmail.com with ESMTPSA id d17sm29653957wrw.88.2019.04.05.00.49.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Apr 2019 00:49:19 -0700 (PDT) Date: Fri, 5 Apr 2019 09:49:17 +0200 From: Stefano Garzarella To: "Michael S. Tsirkin" Cc: netdev@vger.kernel.org, Jason Wang , Stefan Hajnoczi , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH RFC 0/4] vsock/virtio: optimizations to increase the throughput Message-ID: <20190405074917.ooftpalmploq6x3b@steredhat> References: <20190404105838.101559-1-sgarzare@redhat.com> <20190404114643-mutt-send-email-mst@kernel.org> <20190404164715.sycigtccwq2rziuz@steredhat> <20190404140345-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190404140345-mutt-send-email-mst@kernel.org> User-Agent: NeoMutt/20180716 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Apr 04, 2019 at 02:04:10PM -0400, Michael S. Tsirkin wrote: > On Thu, Apr 04, 2019 at 06:47:15PM +0200, Stefano Garzarella wrote: > > On Thu, Apr 04, 2019 at 11:52:46AM -0400, Michael S. Tsirkin wrote: > > > I simply love it that you have analysed the individual impact of > > > each patch! Great job! > > > > Thanks! I followed Stefan's suggestions! > > > > > > > > For comparison's sake, it could be IMHO benefitial to add a column > > > with virtio-net+vhost-net performance. > > > > > > This will both give us an idea about whether the vsock layer introduces > > > inefficiencies, and whether the virtio-net idea has merit. > > > > > > > Sure, I already did TCP tests on virtio-net + vhost, starting qemu in > > this way: > > $ qemu-system-x86_64 ... \ > > -netdev tap,id=net0,vhost=on,ifname=tap0,script=no,downscript=no \ > > -device virtio-net-pci,netdev=net0 > > > > I did also a test using TCP_NODELAY, just to be fair, because VSOCK > > doesn't implement something like this. > > Why not? > I think because originally VSOCK was designed to be simple and low-latency, but of course we can introduce something like that. Current implementation directly copy the buffer from the user-space in a virtio_vsock_pkt and enqueue it to be transmitted. Maybe we can introduce a buffer per socket where accumulate bytes and send it when it is full or when a timer is fired . We can also introduce a VSOCK_NODELAY (maybe using the same value of TCP_NODELAY for compatibility) to send the buffer immediately for low-latency use cases. What do you think? Thanks, Stefano