[dpdk-dev] [EXT] Re: [PATCH v12 0/2] add IOVA=VA mode support

[Vamsi Krishna Attunuru]

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk at gmail.com>
> Sent: Friday, November 8, 2019 8:24 PM
> To: Ferruh Yigit <ferruh.yigit at intel.com>
> Cc: Vamsi Krishna Attunuru <vattunuru at marvell.com>; dev at dpdk.org;
> thomas at monjalon.net; Jerin Jacob Kollanukkaran <jerinj at marvell.com>; Kiran
> Kumar Kokkilagadda <kirankumark at marvell.com>; olivier.matz at 6wind.com;
> anatoly.burakov at intel.com; arybchenko at solarflare.com;
> stephen at 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.yigit at 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