[dpdk-dev] [PATCH v9 00/24] ethdev: allow unknown link speed

Ferruh Yigit ferruh.yigit at intel.com
Mon Sep 7 15:24:37 CEST 2020


On 8/11/2020 9:52 AM, Ivan Dyukov wrote:

<...>

> 
> v9 changes:
> * remove rte_eth_link_printf function
> * add ETH_LINK_MAX_STR_LEN definition
> * add usage of ETH_LINK_MAX_STR_LEN in examples
> 
> v8 changes:
> * rename rte_eth_link_strf to rte_eth_link_to_str
> * refactor rte_eth_link_to_str according to review comments
> * fix codestyle
> * fix commit message in 02 patch
> * fix compile error in ntb application
> * merge "app" and "doc" commits
> 
> v7 changes:
> * fix meson build
> * change _strf function. now it does not fails in case of unknown specifiers like %d. it just copy it to target string.
> * remove invalid_fmt unit test.
> * add unknown specifier test.
> * fix codestyle
> 
> v6 changes:
> * fix spelling in comments according to checkpatch warning
> 
> v5 changes:
> * rename rte_eth_link_format to rte_eth_link_strf
> * add '\n' to default strings
> * update remaining examples. patch with subj 'examples: new link status print format' contains examples which have no maintainers.
> TBD:
> update remaining nic drivers with 'unknown' speed.  It should be provided in separate patchset.
> 
> v4 changes:
> * refactor rte_eth_link_format using strlcat func instead of snprintf
> * added new checks to unit tests
> * few minor fixes according review comments
> TBD:
> update examples in 'example' folder with new status printing mechanism
> update remaining nic drivers with 'unknown' speed
> 
> v3 changes:
> * remove rte_eth_link_prepare_text function
> * add rte_eth_link_format and rte_eth_link_printf functions
> * added unit tests for rte_eth_link_format function
> TBD:
> update examples in 'example' folder with new status printing mechanism
> update remaining nic drivers with 'unknown' speed
> 
> v2 changes:
> * add function which format link status to textual representation
> * update drivers for Intel nics with 'unknown' speed
> TBD:
> update examples in 'example' folder with new status printing mechanism
> update remaining nic drivers with 'unknown' speed
> 
> v1 changes:
> This is initial patchset which introduces UNKNOWN speed to dpdk
> applications. Also it contains changes related to printf formating.
> Patchset contains changes for app/ and doc/ folders.
> examples/ folder will be provided later.
> 
> 

Hi Ivan,

Logging discussion is going on, this is preventing 'unknown' link speed merged 
and used by drivers. This has potential conflict in more drivers.

So I will get those patches (1,4,5,6/24) although logging link speed won't be 
correct, and logging discussions can continue separately.



Related to the link speed logging, the problem we are trying to solve is 
'unknown' speed value representation (UINT_MAX) won't be correct and can be 
confusing, which requires additional check/parsing before log.

The proposed solution is a link to string function. Because of the logging 
difference/needs in the applications the function provides fine grade logging 
capability, which works fine but I think it is too complex for the problem it is 
solving.
I wonder if the logging link information differences in the applications is an 
actual need, or it happened by time since those samples/applications developed 
by different people and common logging function was missing. So perhaps we can 
switch all to a generic logging.

What do you think following:

For the immediate need for 'unknown' link speed parsing, can have a 
'rte_eth_link_speed_to_str()' function which returns only link speed and 
applications need custom message can use it for logging.

And can have a simple/brief link to string function for generic usage, and if 
application want custom message it can parse link struct itself.
The link string can be something like: "Link Up 10Gbps full-duplex autoneg"



More information about the dev mailing list