Re: [dpdk-dev] [PATCH v3 4/4] ethdev: support MAC address as iterator filter

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, October 22, 2018 3:02 PM
> To: Andrew Rybchenko <arybchenko@solarflare.com>
> Cc: dev@dpdk.org; gaetan.rivet@6wind.com; ophirmu@mellanox.com; Yigit, Ferruh <ferruh.yigit@intel.com>; olivier.matz@6wind.com;
> Horton, Remy <remy.horton@intel.com>; Richardson, Bruce <bruce.richardson@intel.com>; olivier.matz@6wind.com
> Subject: Re: [dpdk-dev] [PATCH v3 4/4] ethdev: support MAC address as iterator filter
> 
> 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 <thomas@monjalon.net>
> >
> > 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