Messages in this thread | | | Date | Tue, 12 Nov 2013 10:16:33 +0800 | Subject | Re: Got iperf regression while intel_iommu is on, how to cut the cost of cache flushing | From | Ethan Zhao <> |
| |
Eric, I do think it is the IO_MMMU reason that brought such performance down, while TSO/TSQ are not the way to cure such wounded performance. I might misunderstand the purpose of TSO/TSQ---get rid of the extra cache flushing pain of mapping and unmapping operation done by Intel IOMMU. (sorry for last HTML mail, resend txt )
Ethan
On Tue, Nov 12, 2013 at 9:34 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > On Tue, 2013-11-12 at 09:03 +0800, Ethan Zhao wrote: >> Eric, >> We have tested the performance with the TSO and TSQ patches >> merged, the result not good, even worse than kernel without those two >> patches. any idea ? >> >> kernel : 3.11.x with TSO & TSQ merged. ( CONFIG_INTEL_IOMMU_DEFAULT_ON=y ) >> Network Interface : eth4 >> Network driver : be2net >> >> Average Bandwidth for : >> 1.tcp-unidirectional test : 4385 Mbits/sec >> 2.tcp-unidirectional-parallel: 9383 Mbits/sec >> 3.tcp-bidirectonal test : 2755 Mbits/sec >> >> vs >> >> kernel : 3.11.x without TSO & TSQ patches. >> (CONFIG_INTEL_IOMMU_DEFAULT_ON is not set) >> Network Interface : eth4 >> Network driver : be2net >> >> Average Bandwidth for : >> 1.tcp-unidirectional test : 7992 Mbits/sec >> 2.tcp-unidirectional-parallel: 9403 Mbits/sec >> 3.tcp-bidirectonal test : 5802 Mbits/sec >> > > So it seems its not the TSO/TSQ changes, but > CONFIG_INTEL_IOMMU_DEFAULT_ON being on instead of off. > > >
| |