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

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

> 
> 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 <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
> > >
> > > 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.

Probably you are right - extra dependency is a less evil here.
Konstantin