From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 029F7A04AD; Wed, 19 Jan 2022 15:24:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 89E8041154; Wed, 19 Jan 2022 15:24:32 +0100 (CET) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id E5D3A41147 for ; Wed, 19 Jan 2022 15:24:31 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 8C4893202823; Wed, 19 Jan 2022 09:24:30 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 19 Jan 2022 09:24:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= jq8R8kUl3aazMU7cWt1LT0HqF/Wu8Pn7VHiRSXvgd0s=; b=YBRN0k7WPbG2J1jo /EOR2s+W+RSNdNNPObqQzMrypQhFE3Fnmr2oaYdehoZVpLoF2FGZKblB36m85SPf pUQRU14cxQdcsPbsXrL1eS4ldqgrsZ1XFUYXfPz7IQ20N/N3mrbkJoSl8IyI+0cQ fvJqDcj8WiHyLomkqJpoG4qNkZB2Z0SK7p6fFbuQj4xi9LcmcYW+jlwaz5p0QIy7 RxG2CJA8GzR4GvpnLwQF+hjCmz7S18OQ8kAM+aOoIPp2b8sJCxrGNeEyEB8CqjJu jQTsU2/NxELUG33SMXLsbWtAhDIXN3vkaCf9JrcY8Fx/FiUgj4/9kgww1s81Eto/ chEOsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=jq8R8kUl3aazMU7cWt1LT0HqF/Wu8Pn7VHiRSXvgd 0s=; b=LBM63PHxoCfRiRNtgrtDa1CgUY+UAUrk4g5D3TXvjQYou8pYhqaKXtK+K GSIuJAHCNrmxQ3pqcsSiQHb3kYBG3L/Zczu0F5mE/k7DsXZximfjvCfJ3q4D+9j5 6zl9gPOPxmliHvawkw/7qujvAODuJpuyvl6Pf6hKtRCVqVOSymIfY1q4x7VA4Qf3 dB0NZdvBamruKSEjfhF1KC7sgjinm80rBU3hyDP+w20FzOzFyCa5DzbhX8b4sUIx eggoxN5kPUafCxu+3VO+uliz2kxgpF8nZjCUcIfKAGOVRv/gTFisNlJAF2j5DcLU JjNyySCcc9YRuDHl+PzvqrhjRRvQA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeigddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdevuedt jeevheevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 19 Jan 2022 09:24:28 -0500 (EST) From: Thomas Monjalon To: Morten =?ISO-8859-1?Q?Br=F8rup?= , Stephen Hemminger , "Randles, Ronan" , "Van Haaren, Harry" , "Ananyev, Konstantin" Cc: dev@dpdk.org Subject: Re: [PATCH 02/12] net: add function to pretty print IPv4 Date: Wed, 19 Jan 2022 15:24:27 +0100 Message-ID: <5910655.2l3rmUXbR5@thomas> In-Reply-To: References: <20211214141242.3383831-1-ronan.randles@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D86D72@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 15/12/2021 14:06, Ananyev, Konstantin: >=20 > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > > Sent: Wednesday, 15 December 2021 04.21 > > > > > > On Wed, 15 Dec 2021 01:06:14 +0000 > > > "Ananyev, Konstantin" wrote: > > > > > > --- a/lib/net/rte_ip.h > > > > > > +++ b/lib/net/rte_ip.h > > > > > > @@ -444,6 +444,26 @@ __rte_experimental > > > > > > int32_t > > > > > > rte_ip_parse_addr(const char *src_ip, uint32_t *output_addr); > > > > > > > > > > > > + > > > > > > +/** > > > > > > + * Print IP address from 32 bit int into char * buffer. > > > > > > + * > > > > > > + * @param ip_addr > > > > > > + * ip address to be printed. > > > > > > + * @param buffer > > > > > > + * The buffer the string will be saved into. > > > > > > + * @param buffer_size > > > > > > + * size of buffer to be used. > > > > > > + * > > > > > > + * @retval 0 > > > > > > + * Success. > > > > > > + * @retval -1 > > > > > > + * Failure due to invalid input arguments. > > > > > > + */ > > > > > > +__rte_experimental > > > > > > +int32_t > > > > > > +rte_ip_print_addr(uint32_t ip_addr, char *buffer, uint32_t > > > > > > buffer_size); > > > > > > + > > > > > > > > > > In continuation of my email reply about the IPv4 parse function... > > > > > > > > > > I have a few suggestions to the IPv4 print function too: > > > > > > > > > > The return value should be the number of characters written to the > > > output string, and still -1 on error. With this modification, you cou= ld > > > > > use the return type ssize_t instead of int32_t. > > > > > > > > > > Furthermore, I would prefer having the parameters in the same ord= er > > > as snprintf(): char *str, size_t size, const uint32_t ip_addr. Please > > > > > also notice the suggested changed type for the size, and the const > > > added to the ip_addr. > > > > > > > > > Honestly, I don't understand why we need to introduce such functions > > > > inside DPDK at all. > > > > What's wrong with existing standard ones: inet_ntop() and > > > inet_pton()? > > > > > > Agreed, I see no added value in reinventing here > >=20 > > I think that DPDK functions for converting all sorts of types to/from s= trings would be useful; not only IP addresses, but also MAC addresses, > > TCP/UDP port numbers and VLAN IDs. >=20 > For MACs we already have: > rte_ether_format_addr()/rte_ether_unformat_addr() >=20 > >=20 > > If you don't like IP address string conversion functions in the net lib= rary, DPDK could have a string conversions library. That library could > > expose a multitude of APIs for the same purpose, so the application can= use the API that best fits each application use. >=20 > I don=E2=80=99t mind to add new functions into net lib, if they are usefu= l ones. > But for that particular case, I just don't see what is the reason to > develop and maintain our own functions while existing analogues: > - are well known, widely adopted and field proven > - do provide the same or even more comprehensive functionality +1 Waiting for an answer from the authors. One month silence so far.