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

Ferruh Yigit ferruh.yigit at intel.com
Mon Mar 22 15:03:07 CET 2021


On 3/22/2021 1:58 PM, 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?
> 
>> 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.

Can you also put a separate line to document the Rx function selection order if 
the ``rx_func_hint`` is not provided. Same for Tx.


More information about the dev mailing list