All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: tosher 1 <akm2tosher@yahoo.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Xen network domain performance for 10Gb NIC
Date: Mon, 27 Apr 2020 09:03:17 +0200	[thread overview]
Message-ID: <20200427070317.GL28601@Air-de-Roger> (raw)
In-Reply-To: <1359850718.562651.1587928713792@mail.yahoo.com>

On Sun, Apr 26, 2020 at 07:18:33PM +0000, tosher 1 wrote:
>  Hi everyone,
> 
> Lately, I have been experimenting with 10Gb NIC performance on Xen domains. I have found that network performance is very poor for PV networking when a driver domain is used as a network backend.
> 
> My experimental setup is I have two machines connected by the 10Gb network: a server running the Xen hypervisor and a desktop machine working as a client. I have Ubuntu 18.04.3 LTS running on the Dom0, Domus, Driver Domain, and client desktop, where the Xen version is 4.9. I measured the network bandwidth using iPerf3.
> 
> The network bandwidth between a DomU using Dom0 as backend and the client desktop is like 9.39Gbits/sec. However, when I use a network driver domain, which has the 10Gb NIC by PCI pass through, the bandwidth between the DomU and the client desktop is like 2.41Gbit/sec is one direction and 4.48Gbits/sec in another direction. Here, by direction, I mean the client-server direction for iPerf3.
> 
> These results indicate a huge performance degradation, which is unexpected. I am wondering if I am missing any key points here which I should have taken care of or if there is any tweak that I can apply.

Driver domains with passthrough devices need to perform IOMMU
operations in order to add/remove page table entries when doing grant
maps (ie: IOMMU TLB flushes), while dom0 doesn't need to because it
has the whole RAM identity mapped in the IOMMU tables. Depending on
how fast your IOMMU is and what capabilities it has doing such
operations can introduce a significant amount of overhead.

I would give a try to a newer version of Xen also, there have been
some changes in IOMMU management, but I would guess your bottleneck
doesn't come from the code itself, but rather from the IOMMU.

Roger.


  parent reply	other threads:[~2020-04-27  7:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1359850718.562651.1587928713792.ref@mail.yahoo.com>
2020-04-26 19:18 ` Xen network domain performance for 10Gb NIC tosher 1
2020-04-27  5:28   ` Jürgen Groß
2020-04-27 19:27     ` tosher 1
2020-04-27  7:03   ` Roger Pau Monné [this message]
2020-04-28  5:23     ` tosher 1
2020-04-28  7:07       ` Roger Pau Monné
2020-04-28 16:08         ` tosher 1
2020-04-28 16:21           ` Roger Pau Monné

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=20200427070317.GL28601@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=akm2tosher@yahoo.com \
    --cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.