> -----Original Message----- > From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com] > Sent: Thursday, October 27, 2016 5:55 PM > To: Wang, Zhihong <zhihong.wang at intel.com>; Yuanhan Liu > <yuanhan.liu at linux.intel.com>; stephen at networkplumber.org; Pierre > Pfister (ppfister) <ppfister at cisco.com> > Cc: Xie, Huawei <huawei.xie at intel.com>; dev at dpdk.org; > vkaplans at redhat.com; mst at redhat.com > Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support > to the TX path > > > > On 10/27/2016 11:10 AM, Maxime Coquelin wrote: > > Hi Zhihong, > > > > On 10/27/2016 11:00 AM, Wang, Zhihong wrote: > >> Hi Maxime, > >> > >> Seems indirect desc feature is causing serious performance > >> degradation on Haswell platform, about 20% drop for both > >> mrg=on and mrg=off (--txqflags=0xf00, non-vector version), > >> both iofwd and macfwd. > > I tested PVP (with macswap on guest) and Txonly/Rxonly on an Ivy Bridge > > platform, and didn't faced such a drop. > > Have you tried to pass indirect_desc=off to qemu cmdline to see if you > > recover the performance? > > > > Yuanhan, which platform did you use when you tested it with zero copy? > > > >> > >> I'm using RC2, and the CPU is Xeon E5-2699 v3 @ 2.30GHz. > >> > >> Could you please verify if this is true in your test? > > I'll try -rc1/-rc2 on my platform, and let you know. > As a first test, I tried again Txonly from the guest to the host (Rxonly), > where Tx indirect descriptors are used, on my E5-2665 @2.40GHz: > v16.11-rc1: 10.81Mpps > v16.11-rc2: 10.91Mpps > > -rc2 is even slightly better in my case. > Could you please run the same test on your platform?
I mean to use rc2 as both host and guest, and compare the perf between indirect=0 and indirect=1. I use PVP traffic, tried both testpmd and OvS as the forwarding engine in host, and testpmd in guest. Thanks Zhihong > > And could you provide me more info on your fwd bench? > Do you use dpdk-pktgen on host, or you do fwd on howt with a real NIC > also? > > Thanks, > Maxime > > Thanks, > > Maxime > > > >> > >> > >> Thanks > >> Zhihong > >> > >>> -----Original Message----- > >>> From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com] > >>> Sent: Monday, October 17, 2016 10:15 PM > >>> To: Yuanhan Liu <yuanhan.liu at linux.intel.com> > >>> Cc: Wang, Zhihong <zhihong.wang at intel.com>; Xie, Huawei > >>> <huawei.xie at intel.com>; dev at dpdk.org; vkaplans at redhat.com; > >>> mst at redhat.com; stephen at networkplumber.org > >>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors > >>> support > >>> to the TX path > >>> > >>> > >>> > >>> On 10/17/2016 03:21 PM, Yuanhan Liu wrote: > >>>> On Mon, Oct 17, 2016 at 01:23:23PM +0200, Maxime Coquelin wrote: > >>>>>> On my side, I just setup 2 Windows 2016 VMs, and confirm the issue. > >>>>>> I'll continue the investigation early next week. > >>>>> > >>>>> The root cause is identified. > >>>>> When INDIRECT_DESC feature is negotiated, Windows guest uses > indirect > >>>>> for both Tx and Rx descriptors, whereas Linux guests (Virtio PMD & > >>>>> virtio-net kernel driver) use indirect only for Tx. > >>>>> I'll implement indirect support for the Rx path in vhost lib, but the > >>>>> change will be too big for -rc release. > >>>>> I propose in the mean time to disable INDIRECT_DESC feature in vhost > >>>>> lib, we can still enable it locally for testing. > >>>>> > >>>>> Yuanhan, is it ok for you? > >>>> > >>>> That's okay. > >>> I'll send a patch to disable it then. > >>> > >>>> > >>>>> > >>>>>> Has anyone already tested Windows guest with vhost-net, which > also > >>> has > >>>>>> indirect descs support? > >>>>> > >>>>> I tested and confirm it works with vhost-net. > >>>> > >>>> I'm a bit confused then. IIRC, vhost-net also doesn't support indirect > >>>> for Rx path, right? > >>> > >>> No, it does support it actually. > >>> I thought it didn't support too, I misread the Kernel implementation of > >>> vhost-net and virtio-net. Acutally, virtio-net makes use of indirect > >>> in Rx path when mergeable buffers is disabled. > >>> > >>> The confusion certainly comes from me, sorry about that. > >>> > >>> Maxime