All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@huawei.com>
To: trump_zhang <trump_zhang@126.com>, xen-devel@lists.xen.org
Subject: Re: Question about significant network performance difference after pin RX netback to vcpu0
Date: Thu, 8 Jan 2015 15:30:36 +0000	[thread overview]
Message-ID: <54AEA29C.2000208@huawei.com> (raw)
In-Reply-To: <28b9de05.ef73.14ac7638a98.Coremail.trump_zhang@126.com>



On 08/01/2015 02:33, trump_zhang wrote:
> Hi,
>      I am trying to test the single-queue networking performance for
> netback/netfront in upstream, my testing environment is as follows:
>      1. Using pkt-gen to send a single UDP flow from one host to a vm
> which runs on another XEN host. Two hosts are connected with 10GE
> network (Intel 82599 NIC, which has multiqueue support)
>      2. The receiver XEN host uses xen 4.4, and dom0's OS is Linux
> 3.17.4 which already has multiqueue netback support
>      3. The receiver XEN host's CPU is NUMA, and cpu0-cpu7 belong to the
> same node
>      4. The receiver Dom0 has 6 VCPU and 6G Memory, and the vcpu/mem is
> "pinned" to host by using "dom0_vcpu_num=4 dom0_vcpus_pin
> dom0_mem=6144M" args during boot
I guess you wanted to say dom0_vcpu_num=6.

>      5. The receiver VM has 4 vcpu and 4G memory, and vcpu0 is pinned to
> pcpu 6 which means the vcpu0 is running on the same numa node with dom0
It can be that Dom0 is using the same pcpu, see my previous mail:

http://lists.xen.org/archives/html/xen-devel/2015-01/msg00564.html

>
>      During testing, I have modified the sender host's IP address to
> make the receiver host and vm have behaviors as follows:
>      1. The queue 5 of NIC in Dom0 handles the flow, which can be
> confirmed from  "/proc/interrupts". As a result, the "ksoftirqd/5"
> process will run with some cpu usage during testing, which can be
> confirmed from the result of "top" command
>      2. The queue 2 of netback vif handles the flow, which can be
> confirmed from the result of "top" command in Dom0 (which shows that the
> "vif1.0-guest-q2" process runs with some cpu usage)
>      3. The "ksfotirqd/0" (which running on vcpu0) in DomU runs with
> some high cpu usage, and it seems that this process handles the soft
> interrupt of RX
>
>      However, I find some strange phenomenon as follows:
>      1. All RX interrupts of netback vif are only sent to queue 0, which
> can be confirmed from the content of "/proc/interrupts" file in Dom0.
> But other than "ksoftirqd/0", it seems that  "ksoftirqd/2" will handle
> the soft interrupt and run with high cpu usage when the
> "vif1.0-guest-q2" process runs on vpu2. But why not the ksortirqd/0
> handles the soft interrupt because the RX interrupts are sent to queue0?
Can you check in /proc/interrupts which interrupts are served on vcpu#2 
in an excessive number? Do you have irqbalance running and shifting 
interrupts around?

>   I have also tried to make another queue of netback VIF (e.g.
> vif1.0-guest-q1, vif1.0-guest-q3, etc) to handle the flow, but all RX
> interrupts are still only sent to vcpu0, I am wondering the reason for it?
The NIC driver's receive function usually calls to the 
bridge/openvswitch code (depending on what you have), and that calls 
directly xenvif_start_xmit. There, skb_get_queue_mapping(skb) tells 
netback which queue should be used. It seems to me NIC drivers set this 
value to the receive queue number, or nothing at all, which defaults to 
0. Check your NIC driver, look for "queue_mapping"

>      2. The RX interrupts are sent to queue 2 of vnic in DomU, but it
> seems that it is the "ksoftirqd/0" other than "ksoftirqd/2" handles the
> soft interrupt.
Again, check what interrupts are served on vcpu#0 in guest.

>      3. If and only if I "pin" the "vif1.0-guest-q2" process to the
> vcpu0 of Dom0, the throughout of flow is higher (which can be improved
> as much as double). This is the most strange phenomenon I find, I am
> wondering the reason for it.
>
>     Could anyone give me some hint about it? If there are some things
> unclear, please tell me and I will give more detailed description. Thanks.
>
> -------------------
> Best Regards
> Trump
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

      reply	other threads:[~2015-01-08 15:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-08  2:33 Question about significant network performance difference after pin RX netback to vcpu0 trump_zhang
2015-01-08 15:30 ` Zoltan Kiss [this message]

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=54AEA29C.2000208@huawei.com \
    --to=zoltan.kiss@huawei.com \
    --cc=trump_zhang@126.com \
    --cc=xen-devel@lists.xen.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.