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"
