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 E16A1A04AA; Tue, 8 Sep 2020 08:16:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 75A5F1B9B7; Tue, 8 Sep 2020 08:16:09 +0200 (CEST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id C6C032BAB for ; Tue, 8 Sep 2020 08:16:07 +0200 (CEST) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20200908061607euoutp028aea82ac03c455d8e6f0f330d5666b46~yumaGXAob0685706857euoutp02u; Tue, 8 Sep 2020 06:16:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20200908061607euoutp028aea82ac03c455d8e6f0f330d5666b46~yumaGXAob0685706857euoutp02u DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1599545767; bh=NR/iGfq8vodeYW85oz4q/ptkfxxZ5X3eQy9wp7e2F3Q=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=vS3YhVzzdmCjGaHYakc9pvWgc/AvBsWnFXr6PRdOoRWKKwt7uLSjNXMbDt6UYJjGt Te9vsJ32SQY4pccCSASvQ1qNikQLnmfkPu20bXBwkeS5NL5yN8KRgSSlKUM37YzX8E f+m4Yw1e0vgiUbCMJNe2uG/7JUlPxNKx4femrCGI= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20200908061606eucas1p2247281abf30252907af5a79b9572b841~yumZ4y6lo2413324133eucas1p2D; Tue, 8 Sep 2020 06:16:06 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id 30.EC.06318.6A1275F5; Tue, 8 Sep 2020 07:16:06 +0100 (BST) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20200908061606eucas1p1ae857443aa6ed19c722ec1e8a903e08a~yumZgQ-HR1218712187eucas1p1X; Tue, 8 Sep 2020 06:16:06 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20200908061606eusmtrp2b83abf2dddc474dfe098c7b0ec7c7a7a~yumZeQuII2744227442eusmtrp2P; Tue, 8 Sep 2020 06:16:06 +0000 (GMT) X-AuditID: cbfec7f5-371ff700000018ae-e9-5f5721a647d0 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id B5.CF.06017.6A1275F5; Tue, 8 Sep 2020 07:16:06 +0100 (BST) Received: from [106.109.129.29] (unknown [106.109.129.29]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20200908061604eusmtip27fe42e2094a873abd83ede877aabb399~yumXpkkk70805008050eusmtip2e; Tue, 8 Sep 2020 06:16:04 +0000 (GMT) To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , 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, 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 From: Ivan Dyukov Message-ID: Date: Tue, 8 Sep 2020 09:16:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C612B3@smartserver.smartshare.dk> Content-Transfer-Encoding: 8bit Content-Language: ru-RU X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0xTZxj2O+f0nAOz5FDdeOc1VDMHmyAXkzeZ98s8W8JkWXZhy8Y6PEMD raQVJv4wVbRqUZTOjAiTa4asI4FNoJRRNxpHYUWcNWaSWMTLhrgBFSyKgpfjwci/53m+53m/ 9/ny8bTmLDuH32bYIRkNukwtG8o0tY93L62O/Dh12aF78VjXVUrwem8VjX3H/SzmB/ZReNm+ Glsd36vQdtVMYYHtDoWOGiuL//ftZXBoxEHhFZeXw998HhZH3P0cHjlfQrB/4jaNJ8pHCZ4v bVTheFsLi8MTlQwWPLhE8GhDB0HP4TsMHnc2E7RYBQz8eIrDqisLcKSvg0Fvz2kOa4MXaGzs miRY6KkjeM7yWLUmUnxQ/oNKrGodoMRvKy7QYnvPd5x4uLOUEn8eaqbE4TOXWLGgwU7EP6/n 0+JPN++z4q8jNib5pU9DV2yRMrflSMbYVV+Gbv2rN6jK6ord2WvfYCaFS6yE50FIBGfXWisJ 5TVCDYGgv4oo5C6Be64gayUhT8koAXdwhYzlQNn9fSrFdIrAvwEXo5BhAo7uG5w8dpbwDkze eEsOzBa+hlsXbzIypgULC3V5m2XMCq+D92ApJWO1sAo89bdoOcoIi6G/dbcsvyykgPOfAU6x hEPnCWVMiLAZaqzjtDJyIeQ1lkzhCAg42lh5HRCKQsA6WMYoS2+AP+rbKAXPgtueBk7B8+Cx s4xSAgcIFDad5hRyjEBeyeCUazU0/Nf9rBgtREFdS6wir4X8k2Os8oxhcHkwXFkiDGxNRbQi q+GgRaO4tfB7p29KBph8OPMY0RZPa1Y8rU3xtDbFL64tJ4ydREjZJn26ZEowSN/EmHR6U7Yh PSZtu/4X8vRvex95gs3kzMRXbiLwRDtTLSZ9lKpR6XJMuXo3AZ7WzlavO+f9QqPeosvdJRm3 pxqzMyWTm8zlGW2EOqFy4HONkK7bIWVIUpZkfH5K8SFzzGTPh4mVBWWG6OSMyMl4c9ZriUmb 7O/7l1dUpH8W92bt4qLcD7xXh5Ln51A748PeXbYx/o2ebH9U3JLRjErfxNKolfuTxbHojibL vAT/e2xE5/4Un0tfvyhzY5T52iubrnEznBdrHr76d9tgdZJtpYtec8QXEGLyaz+Jffvs+u40 brlrTMuYturiommjSfcEpO0oL9cDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0xTVxjAc+6rBa07VgwnmPi4WaLReLG8+nUqPpPdaaImRoxPaPQKBEpd bzG+JUoIVsXBiEI1BSWiIAYVKjDZlM5ZXamKBAJOGSoRX4VSJQFSRSqa8N8vOb/fyfcln5JW t7FhyuQ0s2RK06fyXDDj+uzsmFs6Y338vLJmApWNNgQvOkpo6Mx/xsExbyYFbeWLoL7mLAt5 /2dQkJPXR0HNJQsH7zsPM9Djq6Hg6Z8uBdx67OTA5+hWwImHZxB0+9/SUFj8AcFDm52FwYY/ OOj1n2cgZ6gFwcnqewicx/sYyK+rRZBlweAtu6iAkqdTwdd5jwFXe5UCKvqbaLA3fkKQ66xE 4M4aZhfPEIeKL7BiSf0bSvz9XBMt3m0/pRCP37dR4rWeWkrs/auFE3Oqy5H474tjtHi5a4AT b/rymDXjNgoLTMZ0szQ9ySibF/KbNBAhaHQgRETpBE2kdstPEdF8eOyC7VJq8i7JFB6bICQ9 6uhndzaG7+4oX56BcmdaUJCS4ChSNJDJWlCwUo0vIPKu8wljQcqRB0LeddGjziTib7Vwo44H EY+znQ04k/Av5NPL+QEnBO8gmQX/fXVonMWRBy1uNBrYKTLQchkFLA7PIq5sGxVgFY4lzquv 6cBHDP6RdNcfDOBkvIHU1epGjYnkfmEXE+AgvJpcsgx+nYfGMcRW9fwbTyNH7Ge+cSjx1jRw vyG1dUxuHZNYxyTWMUkxYspRiJQuGxINcoQg6w1yelqisM1ouI5GrurG3cHqWmTpWetAWIn4 8Srvirh4NavfJe8xOBBR0nyIaqnbtVWt2q7fs1cyGeNN6amS7EDRI6vl0mGTtxlHbjTNHK+J 1mhBp9FGaiNjgA9VZeOGzWqcqDdLKZK0UzJ97yhlUFgG2u+fMvzSXQlC3MreX28nz1vZVPTq I4+9h8vqGq+4c7taHx36YJ7w/O9bR1PfiguFuI+qmeeb5dvanvDT65rvoKIlSw78XEUPZdxs j/nH658d8xgHVWQfKO1v88wtzff4QjV7h0zBrTp7YUWiI2GOtTmpYN+y4R8UKQlRHj5l1YQ+ npGT9JrZtEnWfwGMxtuTawMAAA== X-CMS-MailID: 20200908061606eucas1p1ae857443aa6ed19c722ec1e8a903e08a X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200811085300eucas1p17b6087e1ba9a84f7cbefd6f042a6ddaa X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200811085300eucas1p17b6087e1ba9a84f7cbefd6f042a6ddaa References: <20200427095737.11082-1-i.dyukov@samsung.com> <20200811085246.28735-1-i.dyukov@samsung.com> <98CBD80474FA8B44BF855DF32C47DC35C612B3@smartserver.smartshare.dk> 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" Hi Ferruh, Morten, 07.09.2020 18:29, Morten Brørup пишет: >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit >> Sent: Monday, September 7, 2020 3:25 PM >> >> 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 >>> >>> 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. > Good thinking, Ferruh. I agree that examples probably use different formatting by accident, not by deliberate choice. >> 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. > That function is unlikely to serve application specific needs for formatting speed. > > But it might serve the needs of DPDK libraries and examples. > >> 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" >> > For DPDK libraries and examples, I agree that a generic one-format-fits-all function should suffice. > > And as a DPDK application developer, parsing the link struct ourselves suffices for our application. In this context, an strf-style function is "nice to have", not "must have". Almost all examples have same link status formating, except two cases: testpmd has multiline link status format and another application has extremely brief status info which is mixed with other text.  so I would prefer to keep such statuses without changes but we should give some helpers for such cases.I would prefer MACROS: #define RTE_ETH_LINK_STATUS_TO_STR(link_status) (link_status == ETH_LINK_DOWN ? "Down" : "Up") #define RTE_ETH_LINK_SPEED_TO_STR(link_speed)  (link_speed == ETH_SPEED_NUM_UNKNOWN ? "Unknown" : \                                           link_speed == ETH_SPEED_NUM_NONE    ? "0" : \                                           link_speed == ETH_SPEED_NUM_10M     ? "10 Mbps" : \                                           link_speed == ETH_SPEED_NUM_100M    ? "100 Mbps" : \                                           link_speed == ETH_SPEED_NUM_1G      ? "1 Gbps" : \                                           link_speed ==ETH_SPEED_NUM_2_5G    ? "2.5 Gbps" : \                                           link_speed ==ETH_SPEED_NUM_5G      ? "5 Gbps" : \                                           link_speed ==ETH_SPEED_NUM_10G     ? "10 Gbps" : \                                           link_speed == ETH_SPEED_NUM_20G     ? "20 Gbps" : \                                           link_speed == ETH_SPEED_NUM_25G ? "25 Gbps" : \                                           link_speed == ETH_SPEED_NUM_40G ? "40 Gbps" : \                                           link_speed == ETH_SPEED_NUM_50G ? "50 Gbps" : \                                           link_speed == ETH_SPEED_NUM_56G ? "56 Gbps" : \ link_speed == ETH_SPEED_NUM_100G    ? "100 Gbps" : \ link_speed == ETH_SPEED_NUM_200G    ? "200 Gbps" : \                                           "Invalid speed") #define RTE_ETH_LINK_DUPLEX_TO_STR(link_duplex)  (link_duplex == ETH_LINK_FULL_DUPLEX? "FDX" : "HDX") #define RTE_ETH_LINK_AUTONEG_TO_STR(link_autoneg)  (link_autoneg== ETH_LINK_FULL_DUPLEX? "Autoneg" : "Fixed") and one function which construct a default status string: int rte_eth_link_to_str(char *str, size_t len, const struct rte_eth_link *eth_link) {  static const char link_down_str[] = "Link down";  static const char link_up_str[] = "Link up at";  if (eth_link->link_status == ETH_LINK_DOWN)         return snprintf(str, len, "%s", link_down_str);   else   return snprintf(str, len, "%s %s %s %s", link_up_str, RTE_ETH_LINK_SPEED_TO_STR(eth_link->link_speed), RTE_ETH_LINK_DUPLEX_TO_STR(eth_link->link_duplex), RTE_ETH_LINK_AUTONEG_TO_STR(eth_link->link_autoneg)); } > Med venlig hilsen / kind regards > - Morten Brørup > > >