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

Jerin Jacob jerinjacobk at gmail.com
Fri Nov 8 15:54:20 CET 2019


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?
>
> Regards,
> ferruh


More information about the dev mailing list