[dpdk-dev] [PATCH v5 1/8] net/hns3: support runtime config to select IO burst func

[Ferruh Yigit]

On 3/23/2021 3:31 AM, fengchengwen wrote:
> 
> 
> On 2021/3/22 21:58, Ferruh Yigit wrote:
>> On 3/19/2021 1:07 AM, Min Hu (Connor) wrote:
>>> From: Chengwen Feng <fengchengwen at 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?
> 
> I'm sorry to confuse you, let me explain the hns3 sve function history:
> 1. The sve instruction only support on our latest processor Kunpeng930, and
> the sve Rx/Tx function is being gradually optimized.
> 2. We define a macro CONFIG_RTE_LIBRTE_HNS3_INC_VECTOR_SVE which equal n
> default in the original scheme, so driver will not select sve Rx/Tx function
> unless user config CONFIG_RTE_LIBRTE_HNS3_INC_VECTOR_SVE=y.
> 3. We plan to switch CONFIG_RTE_LIBRTE_HNS3_INC_VECTOR_SVE equal y when the
> sve Rx/Tx function is fully optimized.
> 4. The makefile is switched to meson build in 20.11, and it's not recommended
> to define the marco such as above, so the upload scheme is adjusted which
> delete the macro CONFIG_RTE_LIBRTE_HNS3_INC_VECTOR_SVE, this leads to driver
> select sve Rx/Tx function when meeting sve conditions (which are gcc support
> compile sve and the host cpu&os support sve), but it doesn't fit out plan, so
> here we modify it.
> 

Got it, so you want keep the 'neon' path default until 'sve' path is more 
optimized, thanks for clarification.

>>
>>> Signed-off-by: Chengwen Feng <fengchengwen at huawei.com>
>>> Signed-off-by: Min Hu (Connor) <humin29 at 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.
>>
>> .
> 
> OK, will fix in later patch
>