On 17-Jul-19 9:33 AM, Jerin Jacob Kollanukkaran wrote:
-----Original Message-----
From: Burakov, Anatoly <anatoly.bura...@intel.com>
Sent: Tuesday, July 16, 2019 8:03 PM
To: Jerin Jacob Kollanukkaran <jer...@marvell.com>; dev@dpdk.org; John
McNamara <john.mcnam...@intel.com>; Marko Kovacevic
<marko.kovace...@intel.com>
Cc: tho...@monjalon.net; david.march...@redhat.com
Subject: [EXT] Re: [dpdk-dev] [PATCH v2 4/4] eal: select IOVA mode as VA for
default case
On 16-Jul-19 2:46 PM, jer...@marvell.com wrote:
From: Jerin Jacob <jer...@marvell.com>
When bus layer selected the preferred mode as RTE_IOVA_DC then select
the IOVA mode as RTE_IOVA_VA.
The RTE_IOVA_VA selected as the default because,
1) All drivers work in RTE_IOVA_VA mode, irrespective of physical
address availability.
2) By default, the mempool, first asks for IOVA-contiguous memory
using RTE_MEMZONE_IOVA_CONTIG and this is slow in IOVA as PA mode
and
it may affect the application boot time.
Signed-off-by: Jerin Jacob <jer...@marvell.com>
---
I should celebrate now :D
doc/guides/prog_guide/env_abstraction_layer.rst | 10 ++++++++--
lib/librte_eal/linux/eal/eal.c | 6 ++----
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst
b/doc/guides/prog_guide/env_abstraction_layer.rst
index 77307e3a6..1b0343eee 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -445,8 +445,14 @@ kernels.
- if the preferred mode is RTE_IOVA_PA but there is no access to Physical
Addresses, then EAL init will fail early, since later probing of the
devices
would fail anyway,
-- if the preferred mode is RTE_IOVA_DC then based on the Physical
Addresses
- availability, the preferred mode is adjusted to RTE_IOVA_PA or
RTE_IOVA_VA.
+- if the preferred mode is RTE_IOVA_DC then select the IOVA mode as
RTE_IOVA_VA.
+ The RTE_IOVA_VA selected as the default because,
+
+#. All drivers work in RTE_IOVA_VA mode, irrespective of physical address
availability.
Is there anywhere we can document that any new driver must support both
before being accepted?
Not sure why new drivers need to support both PA and VA. Do you mean VA?
And not sure where to document this as well if need.
We have a flaf that indicates that the driver needs IOVA as VA. Absence
of said flag indicates that it supports both IOVA as VA and IOVA as PA.
So, absent of this flag, any new driver must support both PA and VA,
must it not?
+
+#. By default, the mempool, first asks for IOVA-contiguous memory using
``RTE_MEMZONE_IOVA_CONTIG``,
+ and this is slow in IOVA as PA mode and it may affect the application
boot time.
I would also add a point about usability improvement for use-cases which
require large amounts of IOVA-contiguous memory.
I will add in next version:
How about the following, Let me know if any change required.
#. It is easy to enable large amount of IOVA-contiguous memory use-cases with
IOVA in VA mode.
Yes, that looks OK.
Otherwise,
Acked-by: Anatoly Burakov <anatoly.bura...@intel.com>
--
Thanks,
Anatoly
