From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 31A26A04B6; Mon, 7 Sep 2020 15:24:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 459BE1C0BE; Mon, 7 Sep 2020 15:24:51 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 15D731BEE1 for ; Mon, 7 Sep 2020 15:24:49 +0200 (CEST) IronPort-SDR: nCMhB4926G+SMs2ezA9Vc4/Wf4c/bYp98/yQVrtRqGwW+JMwHZzMkGWRhkSMRquCuNjGQFgC9h HbY9Fm4uD5eg== X-IronPort-AV: E=McAfee;i="6000,8403,9736"; a="158981236" X-IronPort-AV: E=Sophos;i="5.76,401,1592895600"; d="scan'208";a="158981236" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2020 06:24:49 -0700 IronPort-SDR: /lgJ/InJf4dweg0DBsXM61ARhRBAIG2NKZUvDoEJBjWZ8jeigSvCvMRQMh+yLrCAVyBQd66HD0 Rr9u6ZKhRj9Q== X-IronPort-AV: E=Sophos;i="5.76,401,1592895600"; d="scan'208";a="448424858" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.213.204.196]) ([10.213.204.196]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2020 06:24:40 -0700 To: i.dyukov@samsung.com References: <20200427095737.11082-1-i.dyukov@samsung.com> <20200811085246.28735-1-i.dyukov@samsung.com> From: Ferruh Yigit Cc: dev@dpdk.org, v.kuramshin@samsung.com, thomas@monjalon.net, david.marchand@redhat.com, arybchenko@solarflare.com, wei.zhao1@intel.com, jia.guo@intel.com, beilei.xing@intel.com, qiming.yang@intel.com, wenzhuo.lu@intel.com, mb@smartsharesystems.com, stephen@networkplumber.org, nicolas.chautru@intel.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com, cristian.dumitrescu@intel.com, radu.nicolau@intel.com, akhil.goyal@nxp.com, declan.doherty@intel.com, skori@marvell.com, pbhagavatula@marvell.com, jerinj@marvell.com, kirankumark@marvell.com, david.hunt@intel.com, anatoly.burakov@intel.com, xiaoyun.li@intel.com, jingjing.wu@intel.com, john.mcnamara@intel.com, jasvinder.singh@intel.com, byron.marohn@intel.com, yipeng1.wang@intel.com, Gaetan Rivet Message-ID: Date: Mon, 7 Sep 2020 14:24:37 +0100 MIME-Version: 1.0 In-Reply-To: <20200811085246.28735-1-i.dyukov@samsung.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v9 00/24] ethdev: allow unknown link speed X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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"