On 11/13/2019 6:33 AM, Vamsi Krishna Attunuru wrote: > >> -----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. >
Hi Vamsi, >From my perspective there is no other change request than the documentation update, I suggest sending new version. For the final decision, it can be in technical board but there is no meeting this week, so I will start an offline discussion. Thanks, ferruh
