From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 266831B0FC for ; Tue, 23 Oct 2018 10:33:11 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 01:33:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,415,1534834800"; d="scan'208";a="243580333" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga004.jf.intel.com with ESMTP; 23 Oct 2018 01:33:09 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.45]) by IRSMSX109.ger.corp.intel.com ([169.254.13.183]) with mapi id 14.03.0319.002; Tue, 23 Oct 2018 09:33:08 +0100 From: "Ananyev, Konstantin" To: Thomas Monjalon CC: Andrew Rybchenko , "dev@dpdk.org" , "gaetan.rivet@6wind.com" , "ophirmu@mellanox.com" , "Yigit, Ferruh" , "olivier.matz@6wind.com" , "Horton, Remy" , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v3 4/4] ethdev: support MAC address as iterator filter Thread-Index: AQHUaqDxM0OVcher60extKcno7oXEqUsfKpw Date: Tue, 23 Oct 2018 08:33:07 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580102FEB3BB@IRSMSX106.ger.corp.intel.com> References: <20181009021858.19216-1-thomas@monjalon.net> <1600652.GbAxOGCmMO@xps> <2601191342CEEE43887BDE71AB9772580102FEB060@IRSMSX106.ger.corp.intel.com> <2293154.gpuvSuLZkp@xps> In-Reply-To: <2293154.gpuvSuLZkp@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGY1ZWEyM2ItOTAzZS00MmMzLTgxM2UtYjFlNzliMTczNWQ0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiMFh1ZFVPZ3AxSjBBNGd0ZFFLQzBWQ2hwVmdGcWR0eHVaWDQ4aE53UEdma0U0RVQ3NjZxR0pXVnVIYUEyKzdxbiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 08:33:12 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Tuesday, October 23, 2018 8:21 AM > To: Ananyev, Konstantin > Cc: Andrew Rybchenko ; dev@dpdk.org; gaetan.ri= vet@6wind.com; ophirmu@mellanox.com; Yigit, Ferruh > ; olivier.matz@6wind.com; Horton, Remy ; Richardson, Bruce > > Subject: Re: [dpdk-dev] [PATCH v3 4/4] ethdev: support MAC address as ite= rator filter >=20 > 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 re= solved, > > > > > 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 >=20 > 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. > - 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 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. > - ether_aton_r and my_ether_aton may have a different behavior Could you elaborate here? What exactly would be different? 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 sid= e. If ether_aton_r() just supports extra formats(XXXX:XXXX:XXXX), then it would be extension to current behavior. >=20 > 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. =20