> -----Original Message----- > From: Jerin Jacob <jerinjac...@gmail.com> > Sent: Friday, November 8, 2019 8:24 PM > To: Ferruh Yigit <ferruh.yi...@intel.com> > Cc: Vamsi Krishna Attunuru <vattun...@marvell.com>; dev@dpdk.org; > tho...@monjalon.net; Jerin Jacob Kollanukkaran <jer...@marvell.com>; Kiran > Kumar Kokkilagadda <kirankum...@marvell.com>; olivier.m...@6wind.com; > anatoly.bura...@intel.com; arybche...@solarflare.com; > step...@networkplumber.org > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v12 0/2] add IOVA=VA mode support > > On Fri, Nov 8, 2019 at 7:56 PM Ferruh Yigit <ferruh.yi...@intel.com> wrote: > > > > > > >> Hi Vasim, Jerin, > > >> > > >> Overall looks good and I not getting any functional error but I am > > >> observing a huge performance drop with this update, 3.8Mpps to 0.7Mpps > [1]. > > > > > > Hi Ferruh, > > > When it comes to actual kernel netdev test cases like iperf or any other > > > use > cases, there would not be any impact on performance. I think synthetic test > case > like loopback mode might not be the actual test case alone to depend on when > the kernel module is featured to work with kind of devices(pdev or vdev). > Users > can always fallback to pa mode with cmd line option. > > > > > > Please suggest your thoughts on considering what test case to use & > evaluate the performance difference. > > > > Hi Vasim, > > > > I also assume the real life test cases will be affected less, but the > > loopback performance testing is good to show performance impact of the > change. > > Yes. real-world case Linux kernel stack will be the bottleneck. > > > > > (Stephen's predictions that KNI is not as fast as tun/tap are getting > > more real by time J) > > > > At least I think the possible performance drop and how to mitigate it > > should be documented both in release notes and kni documentation. > > +1 for adding documentation. Setting iova-mode=pa will be mitigation > if the application does > not care about iova-mode. > > > > > For the final decision, I am not objecting it but I would like to see > > more ack from community to confirm that we trade off iova=va > > functionality against performance. > > In my view, IOVA as VA mode case, translation cannot be avoided and we have > the requirement where it needs to work with vdev(where is not backed by any > IOMMU context) so I am not sure how to avoid the translation cost. Since we > have support for both modes,i.e existing IOVA as PA path still exists, I don't > think, we are losing anything. > > > @Jerin, @Thomas, should we conclude this in techboard? Perhaps we can > > get it for > > rc2 and drop it back if rejected in techboard?
Hi Ferruh, Any update on the conclusion about the acceptance of patch set. I will send the next version of patch set with updated documentation part on performance impact if there are no other concerns. Regards A Vamsi > > > > Regards, > > ferruh
