On 3/19/2021 1:07 AM, Min Hu (Connor) wrote:
From: Chengwen Feng <fengcheng...@huawei.com>
Currently, the driver support multiple IO burst function and auto
selection of the most appropriate function based on offload
configuration.
Most applications such as l2fwd/l3fwd don't provide the means to
change offload configuration, so it will use the auto selection's io
burst function.
This patch support runtime config to select io burst function, which
add two config: rx_func_hint and tx_func_hint, both could assign
vec/sve/simple/common.
The driver will use the following rules to select io burst func:
a. if hint equal vec and meet the vec Rx/Tx usage condition then use
the neon function.
b. if hint equal sve and meet the sve Rx/Tx usage condition then use
the sve function.
c. if hint equal simple and meet the simple Rx/Tx usage condition then
use the simple function.
d. if hint equal common then use the common function.
e. if hint not set then:
e.1. if meet the vec Rx/Tx usage condition then use the neon function.
e.2. if meet the simple Rx/Tx usage condition then use the simple
function.
e.3. else use the common function.
Note: the sve Rx/Tx usage condition based on the vec Rx/Tx usage
condition and runtime environment (which must support SVE).
In the previous versions, driver will preferred use the sve function
when meet the sve Rx/Tx usage condition, but in this case driver could
get better performance if use the neon function.
Is this saying 'neon' is giving better performance even if 'sve' is supported?
Signed-off-by: Chengwen Feng <fengcheng...@huawei.com>
Signed-off-by: Min Hu (Connor) <humi...@huawei.com>
---
v6:
- document hns3.rst about description of vec, common and simple.
---
doc/guides/nics/hns3.rst | 19 +++++++++
doc/guides/rel_notes/release_21_05.rst | 1 +
drivers/net/hns3/hns3_ethdev.c | 77 ++++++++++++++++++++++++++++++++++
drivers/net/hns3/hns3_ethdev.h | 15 +++++++
drivers/net/hns3/hns3_ethdev_vf.c | 4 ++
drivers/net/hns3/hns3_rxtx.c | 54 +++++++++++++++++-------
6 files changed, 156 insertions(+), 14 deletions(-)
diff --git a/doc/guides/nics/hns3.rst b/doc/guides/nics/hns3.rst
index 84bd7a3..8f48240 100644
--- a/doc/guides/nics/hns3.rst
+++ b/doc/guides/nics/hns3.rst
@@ -46,6 +46,25 @@ Prerequisites
- Follow the DPDK :ref:`Getting Started Guide for Linux <linux_gsg>` to setup
the basic DPDK environment.
+Runtime Config Options
+----------------------
+
+- ``rx_func_hint`` (default ``none``)
+
+ Used to select Rx burst function, supported value are "vec", "sve", "simple",
"common".
``vec``, ``sve``, ``simple`` and ``common``. ??
+ When equal "vec" and meet the vector Rx usage condition then use the default
vector Rx implementation, 'neon' for Kunpeng Arm platform.
+ When equal "sve" and meet the sve Rx usage condition then use the sve Rx
function.
+ When equal "simple" and meet the simple Rx usage condition then use the
simple Rx function which indicates the Scalar algorithm obtained from
rte_eth_rx_burst_mode_get.
+ When equal "common" then use the common Rx function which indicates the
Scalar Scattered algorithm obtained from rte_eth_rx_burst_mode_get.
+
A few comments on the documentation,
- What about using `` to highlight the parameter, like ``vec``, on all
occurrences.
- What about adding bullet points for each parameter
- I think you can drop "When equal" start from all
- You can drop "obtained from rte_eth_rx_burst_mode_get" part, the function name
is not needed here, something like gives same information:
- Can "and meet the vector Rx usage condition" be simplified, overall what about
something like:
* ``simple``, if supported use the ``simple`` Rx function which indicates the
scalar algorithm.
- It is not clear what happens when provided parameter is not supported, like
when I set 'vec' but if PMD doesn't support it, which function will be supported?
- Can you please try to limit the line length aroung 80 columns.
- No need to start words with uppercase for 'Scalar' & 'Scalar Scattered'
- Same for below Tx ones.
