From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3 4/4] ethdev: support MAC address as iterator filter Date: Tue, 23 Oct 2018 10:53:56 +0200 Message-ID: <8517734.I65333T3KJ@xps> References: <20181009021858.19216-1-thomas@monjalon.net> <2293154.gpuvSuLZkp@xps> <2601191342CEEE43887BDE71AB9772580102FEB3BB@IRSMSX106.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Andrew Rybchenko , "dev@dpdk.org" , "gaetan.rivet@6wind.com" , "ophirmu@mellanox.com" , "Yigit, Ferruh" , "olivier.matz@6wind.com" , "Horton, Remy" , "Richardson, Bruce" To: "Ananyev, Konstantin" Return-path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 1A7201B3C0 for ; Tue, 23 Oct 2018 10:53:56 +0200 (CEST) In-Reply-To: <2601191342CEEE43887BDE71AB9772580102FEB3BB@IRSMSX106.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 23/10/2018 10:33, Ananyev, Konstantin: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 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 > > Well, it would be *when* will have libc naming conflict resolved. > Till that it would be pretty useful I think. It is planned to be fixed in the next release. > > - cmdline_parse_etheraddr is already used in several places > > As I can see right now it is used just by bond PMD: > $ find lib drivers -type f | xargs grep -l cmdline_parse_etheraddr | grep -v librte_cmdline > drivers/net/bonding/rte_eth_bond_args.c It is also used in examples: examples/bond/main.c examples/ethtool/ethtool-app/ethapp.c examples/l3fwd/main.c examples/performance-thread/l3fwd-thread/main.c > Again if that function is *really* used in several places to convert string to mac, > then I suppose it is an indication that rte_ether_aton() would be useful. > Without forcing cmdline dependency. I don't like wrappers and reinventing the wheel. If we introduce this new wrapper, then we will have to deprecate it, and break the API to remove it. > > - ether_aton_r and my_ether_aton may have a different behavior > > Could you elaborate here? > What exactly would be different? The error path might be slightly different, and... > Both supposed to convert string to ether addr. > If our function can't do that properly, then I think it is a bug in our side. > If ether_aton_r() just supports extra formats(XXXX:XXXX:XXXX), then it > would be extension to current behavior. ... yes there is this extension. > > When the libc conflict will be solved, I prefer replacing uses of > > cmdline_parse_etheraddr one by one. > > We can do the same with rte_ether_aton() too, if we really want to. At the price of breaking the API again.