From: wangyufen <wangyufen@huawei.com>
To: <davem@davemloft.net>
Cc: <joro@8bytes.org>, <Varun.Sethi@freescale.com>, <aik@ozlabs.ru>,
<alex.williamson@redhat.com>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <zhangdianfang@huawei.com>,
Li Zefan <lizefan@huawei.com>
Subject: [Bug Report] use bonding lacp mode aggregation NIC has performance problems while intel_immu switch opening
Date: Fri, 28 Jun 2013 16:59:14 +0800 [thread overview]
Message-ID: <51CD5062.5050501@huawei.com> (raw)
Summary: use bonding lacp mode aggregation NIC has performance problems while intel_immu switch opening
Product: Networking
Version:
Kernel Version: 3.10.0-rc5
Platform: X86
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: bonding&ixgbe
AssignedTo:
ReportedBy: wangyufen@huawei.com,wangweidong1@huawei.com
Regression: No
Hi I'am using bonding lacp mode aggregation intel 82599 NIC, there are performance problems while intel_immu switch is open.
I'am using iperf to test the network speeds.
When intel_immu switch is closed, 4 port after polymerization, the network port speeds up to 37.6 Gbits / sec,
when intel_immu switch is turned on, 4port After polymerization, the network port speed only to 28.7 Gbits / sec.
intel_iommu=off
dma_ops = &swiotlb_dma_ops,so map_page = swiotlb_map_page and unmap_page = swiotlb_unmap_page
intel_iommu=on
dma_ops = &intel_dma_ops,so map_page=intel_map_page and unmap_page=intel_unmap_page
I think the intel_dma_ops will cost more performance, and the dma_map_page and
dma_map_single_attrs will call map_page(),but the paramters is not same. Therefor, I do a test
about the time of funcs call map_page or unmap_page.
----------------------------------------------------------------------------
func\count 350(*10000)
dma_map_single_attrs,iommu-off 640000(ns)~1000000(ns)
dma_map_single_attrs,iommu-on 4900000(ns)~5700000(ns)
dma_unmap_single_attrs,iommu-off 330000(ns)~620000(ns)
dma_unmap_single_attrs,iommu-on 3000000(ns)~47000000(ns)
func\count 2900(*10000)
dma_map_page,iommu-off 350000(ns)~610000(ns)
dma_map_page,iommu-on 2160000(ns)~3000000(ns)
dma_unmap_page,iommu-off 345000(ns)~670000(ns)
dma_unmap_page,iommu-on 3000000(ns)~4300000(ns)
----------------------------------------------------------------------------
the time that map and unmap function cost show huge gap when iommu is on and off.
reply other threads:[~2013-06-28 8:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=51CD5062.5050501@huawei.com \
--to=wangyufen@huawei.com \
--cc=Varun.Sethi@freescale.com \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=davem@davemloft.net \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=zhangdianfang@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox