From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 559BE1B1E3 for ; Tue, 23 Oct 2018 09:20:39 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8430221C08; Tue, 23 Oct 2018 03:20:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 23 Oct 2018 03:20:38 -0400 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=mesmtp; bh=q5NTJbnjJ3YDTCudWmXg1327ylWbEYrYpq+E5n7JsHA=; b=SjLMywb9KXI5 bf9KLg37EHjPntGZyCmrlF8axM0zkBhk/RboUH2LR8kMLEks1LEEs8DFxFfhCfPF sYwBiRdl4Ran4igmVQev2dSpwdmsvZeX+kbbulGV/Mstu8fu1gJ2Z/8z5H0mWpg1 3tsWteo3ET6kjbTMeYi+fljhFeQUnMI= 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=q5NTJbnjJ3YDTCudWmXg1327ylWbEYrYpq+E5n7Js HA=; b=dosh1vcb0nePn5IWTt3iGOSRt5P4g7ujRnkg4EO7GEgVl1yBEGLxYWHOE 7DU2ttT5/AGb1FLvFUquxfNoiDBBqVAr2slPsQsrdyw1lQbndtj8Gym4FKrNUaKP A7HPpTwpXEqod2ITWhkSInMzVgf+PIw6vNx2vh7CFmlOqT4svRE2QJ6vzLn1SDO0 /GFLKlYJ9IXytqXctRXf3HlgyImvNx/mg4wOtfoSE0YN+Ruh3Gp1ZqeO5zZELVnS j8Fo+ZDDdh9TeEfk7c+ClGqwbY2y5TKRVqgumKhIIUKlEV2ZhfuReIWxIFmUfOJG bMRyf19iz1Xs7QuTLdwAccV5ON7Ng== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9FE3F102E4; Tue, 23 Oct 2018 03:20:36 -0400 (EDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: Andrew Rybchenko , "dev@dpdk.org" , "gaetan.rivet@6wind.com" , "ophirmu@mellanox.com" , "Yigit, Ferruh" , "olivier.matz@6wind.com" , "Horton, Remy" , "Richardson, Bruce" Date: Tue, 23 Oct 2018 09:20:37 +0200 Message-ID: <2293154.gpuvSuLZkp@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772580102FEB060@IRSMSX106.ger.corp.intel.com> References: <20181009021858.19216-1-thomas@monjalon.net> <1600652.GbAxOGCmMO@xps> <2601191342CEEE43887BDE71AB9772580102FEB060@IRSMSX106.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 4/4] ethdev: support MAC address as iterator filter 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: , X-List-Received-Date: Tue, 23 Oct 2018 07:20:39 -0000 22/10/2018 23:24, Ananyev, Konstantin: > From: Thomas Monjalon > > 22/10/2018 15:37, Andrew Rybchenko: > > > On 10/22/18 4:15 PM, Thomas Monjalon wrote: > > > > The MAC addresses of a port can be matched with devargs. > > > > > > > > As the conflict between rte_ether.h and netinet/ether.h is not resolved, > > > > the MAC parsing is done with a rte_cmdline function. > > > > As a result, cmdline library becomes a dependency of ethdev. > > > > > > > > Signed-off-by: Thomas Monjalon > > > > > > I'd like to share my thought about a new dependency. > > > Looking at cmdline I think that it is a bad and strange > > > dependency for kvargs. IMHO, even duplication of the > > > code to parse MAC address it less evil in this case. > > > > cmdline is not a dependency for kvargs. > > I have added it as a dependency for ethdev. > > > > > May be it is possible to provide internal wrapper > > > which is implemented using ether_aton_r() and located > > > in a separate C file which does not include rte_ether.h etc? > > > > I raised the issue in technical board and it has been decided to fix the > > conflict with libc in the next release (with Olivier's help). > > So Bruce and me decided to use cmdline function in the meantime. > > As I can see, cmdline_parse_etheraddr() uses > static struct ether_addr * > my_ether_aton(const char *a) > internally. > Why not to make it public, rename to rte_ethet_aton(), > and move into rte_net? > And use that one instead? > Later if/when we'll have name conflict with libc resolved, > It can become just a wrapper around ether_aton_r(). > Konstantin Several reasons: - It would be one more (useless) wrapper - cmdline_parse_etheraddr is already used in several places - ether_aton_r and my_ether_aton may have a different behaviour When the libc conflict will be solved, I prefer replacing uses of cmdline_parse_etheraddr one by one.