Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp8839235ybl; Wed, 25 Dec 2019 07:24:46 -0800 (PST) X-Google-Smtp-Source: APXvYqyM2lf86V+Cl4To24N5XzNZHfwkogbLc68noqIEmUpGJBdMZu0sfY3XXbM6zuGCpFbUEJDa X-Received: by 2002:a9d:51c1:: with SMTP id d1mr42828724oth.136.1577287486795; Wed, 25 Dec 2019 07:24:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577287486; cv=none; d=google.com; s=arc-20160816; b=S39y8qOCMZCgI5EEXiOgXZVkdDHqGMkEsQi+FohOealfvayVedUv3toJeVo/Rmkk1e 5vShiFwsOMoONDwxran0kuIiTmR2g6L42XWrgpU71tJ5mm4ca/aHMqpwrAUDayhO30+z +uy0pTq+ZOuOSDkBFJLNP4MpgbUWBZMnnkuYTQsCqWNMfzQk9tj9zIMAeIiqqOYghboC KzItxZhVW7+1MiTi0hL8aqwNh+UHbZUh6ZJmDp9WaI42BNlPwDCK8zKCj+DEUBOI5u5w vfBaK0h25zv5xVlgZHgHTjMGlBjckY2HKGv49BEpKAcGxzjW77I7DTjNaMy8UFOtQZzG 9LkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=s+3TzeSmZhbpkAvtm/B9C+RpXVpO5P3PFAyt784vJuA=; b=MOqUwqqORM8Mr+r5tcjUD4FO3lxmF87ZMqVwalqCatpz/MlwI1e6N9LvCXLLOSIqo9 3QqJuaploW3PhgVwUBZnLnmbNeRAHjdeQgRyDAWPEF+ZxTdOvw+b87bHUt/xU4/jwkH+ Si1CwgEp7H5a6N5eWPLyP0xeAN5BAl8fbTAWJ5BGXHzNwlKQ/LznQPiWvGV0+hhFm6hE x1Q6brCG7V3BmoUijC1BrLzEOyIGzLJvum6yfGCjGivaylH9Wuo/6GOfZSqZagxFvL2T 8F3r005rvL6AXnlLq+hFGDBRtobZqYi3gMSOspfwGsgxiY8iLEgoHlkFAKGUc99k9FfF 5W+w== 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=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v141si12699888oif.161.2019.12.25.07.24.26; Wed, 25 Dec 2019 07:24:46 -0800 (PST) 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=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726461AbfLYPU6 convert rfc822-to-8bit (ORCPT + 99 others); Wed, 25 Dec 2019 10:20:58 -0500 Received: from out30-45.freemail.mail.aliyun.com ([115.124.30.45]:57532 "EHLO out30-45.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726353AbfLYPU5 (ORCPT ); Wed, 25 Dec 2019 10:20:57 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07486;MF=gerry@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0TlvFgXf_1577287249; Received: from 192.168.0.100(mailfrom:gerry@linux.alibaba.com fp:SMTPD_---0TlvFgXf_1577287249) by smtp.aliyun-inc.com(127.0.0.1); Wed, 25 Dec 2019 23:20:50 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3 From: "Liu, Jiang" In-Reply-To: <229e689d-10f1-2bfb-c393-14dfa9c78971@redhat.com> Date: Wed, 25 Dec 2019 23:20:07 +0800 Cc: Zha Bin , linux-kernel@vger.kernel.org, mst@redhat.com, slp@redhat.com, virtio-dev@lists.oasis-open.org, jing2.liu@intel.com, chao.p.peng@intel.com Content-Transfer-Encoding: 8BIT Message-Id: <0460F92A-3DF6-4F7A-903B-6434555577CC@linux.alibaba.com> References: <229e689d-10f1-2bfb-c393-14dfa9c78971@redhat.com> To: Jason Wang X-Mailer: Apple Mail (2.3445.104.11) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Dec 25, 2019, at 6:20 PM, Jason Wang wrote: > > > On 2019/12/25 上午10:50, Zha Bin wrote: >> From: Liu Jiang >> >> Userspace VMMs (e.g. Qemu microvm, Firecracker) take advantage of using >> virtio over mmio devices as a lightweight machine model for modern >> cloud. The standard virtio over MMIO transport layer only supports one >> legacy interrupt, which is much heavier than virtio over PCI transport >> layer using MSI. Legacy interrupt has long work path and causes specific >> VMExits in following cases, which would considerably slow down the >> performance: >> >> 1) read interrupt status register >> 2) update interrupt status register >> 3) write IOAPIC EOI register >> >> We proposed to update virtio over MMIO to version 3[1] to add the >> following new features and enhance the performance. >> >> 1) Support Message Signaled Interrupt(MSI), which increases the >> interrupt performance for virtio multi-queue devices >> 2) Support per-queue doorbell, so the guest kernel may directly write >> to the doorbells provided by virtio devices. >> >> The following is the network tcp_rr performance testing report, tested >> with virtio-pci device, vanilla virtio-mmio device and patched >> virtio-mmio device (run test 3 times for each case): >> >> netperf -t TCP_RR -H 192.168.1.36 -l 30 -- -r 32,1024 >> >> Virtio-PCI Virtio-MMIO Virtio-MMIO(MSI) >> trans/s 9536 6939 9500 >> trans/s 9734 7029 9749 >> trans/s 9894 7095 9318 >> >> [1] https://lkml.org/lkml/2019/12/20/113 > > > Thanks for the patch. Two questions after a quick glance: > > 1) In PCI we choose to support MSI-X instead of MSI for having extra flexibility like alias, independent data and address (e.g for affinity) . Any reason for not start from MSI-X? E.g having MSI-X table and PBA (both of which looks pretty independent). Hi Jason, Thanks for reviewing patches on Christmas Day:) The PCI MSI-x has several advantages over PCI MSI, mainly 1) support 2048 vectors, much more than 32 vectors supported by MSI. 2) dedicated address/data for each vector, 3) per vector mask/pending bits. The proposed MMIO MSI extension supports both 1) and 2), but the extension doesn’t support 3) because we noticed that the Linux virtio subsystem doesn’t really make use of interrupt masking/unmasking. On the other hand, we want to simplify VMM implementations as simple as possible, and mimicking the PCI MSI-x will cause some complexity to VMM implementations. > 2) It's better to split notify_multiplexer out of MSI support to ease the reviewers (apply to spec patch as well) Great suggestion, we will try to split the patch. Thanks, Gerry > > Thanks