DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: Andrew Rybchenko <arybchenko@solarflare.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"gaetan.rivet@6wind.com" <gaetan.rivet@6wind.com>,
	"ophirmu@mellanox.com" <ophirmu@mellanox.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
	"Horton, Remy" <remy.horton@intel.com>,
	"Richardson, Bruce" <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3 4/4] ethdev: support MAC address as iterator filter
Date: Tue, 23 Oct 2018 10:53:56 +0200	[thread overview]
Message-ID: <8517734.I65333T3KJ@xps> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772580102FEB3BB@IRSMSX106.ger.corp.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.

  reply	other threads:[~2018-10-23  8:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09  2:18 [dpdk-dev] [PATCH 0/4] support more ethdev iterator filters Thomas Monjalon
2018-10-09  2:18 ` [dpdk-dev] [PATCH 1/4] kvargs: support list value Thomas Monjalon
2018-10-09 14:14   ` Gaëtan Rivet
2018-10-09 14:31     ` Thomas Monjalon
2018-10-09 15:11       ` Stephen Hemminger
2018-10-09 17:11         ` Thomas Monjalon
2018-10-10 13:12         ` Remy Horton
2018-10-09  2:18 ` [dpdk-dev] [PATCH 2/4] mk: remove broken check Thomas Monjalon
2018-10-09 11:43   ` Neil Horman
2018-10-09 11:53     ` Thomas Monjalon
2018-10-09 18:11       ` Neil Horman
2018-10-09  2:18 ` [dpdk-dev] [PATCH 3/4] ethdev: move representor parsing functions Thomas Monjalon
2018-10-09  9:06   ` Andrew Rybchenko
2018-10-09 12:38   ` Remy Horton
2018-10-09 13:25     ` Thomas Monjalon
2018-10-09  2:18 ` [dpdk-dev] [PATCH 4/4] ethdev: support representor id for iterating ports Thomas Monjalon
2018-10-09  9:14   ` Andrew Rybchenko
2018-10-10 19:23 ` [dpdk-dev] [PATCH v2 0/4] support more ethdev iterator filters Thomas Monjalon
2018-10-10 19:23   ` [dpdk-dev] [PATCH v2 1/4] kvargs: support list value Thomas Monjalon
2018-10-10 19:23   ` [dpdk-dev] [PATCH v2 2/4] ethdev: move representor parsing functions Thomas Monjalon
2018-10-10 19:23   ` [dpdk-dev] [PATCH v2 3/4] ethdev: support representor id as iterator filter Thomas Monjalon
2018-10-10 19:23   ` [dpdk-dev] [PATCH v2 4/4] ethdev: support MAC address " Thomas Monjalon
2018-10-22 13:15 ` [dpdk-dev] [PATCH v3 0/4] support more ethdev iterator filters Thomas Monjalon
2018-10-22 13:15   ` [dpdk-dev] [PATCH v3 1/4] kvargs: support list value Thomas Monjalon
2018-10-22 13:15   ` [dpdk-dev] [PATCH v3 2/4] ethdev: move representor parsing functions Thomas Monjalon
2018-10-22 13:15   ` [dpdk-dev] [PATCH v3 3/4] ethdev: support representor id as iterator filter Thomas Monjalon
2018-10-22 13:15   ` [dpdk-dev] [PATCH v3 4/4] ethdev: support MAC address " Thomas Monjalon
2018-10-22 13:37     ` Andrew Rybchenko
2018-10-22 14:02       ` Thomas Monjalon
2018-10-22 14:18         ` Andrew Rybchenko
2018-10-22 21:24         ` Ananyev, Konstantin
2018-10-23  7:20           ` Thomas Monjalon
2018-10-23  8:33             ` Ananyev, Konstantin
2018-10-23  8:53               ` Thomas Monjalon [this message]
2018-10-23 21:45                 ` Ananyev, Konstantin
2018-10-22 14:25     ` Andrew Rybchenko
2018-10-24  8:27   ` [dpdk-dev] [PATCH v3 0/4] support more ethdev iterator filters Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8517734.I65333T3KJ@xps \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=gaetan.rivet@6wind.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=ophirmu@mellanox.com \
    --cc=remy.horton@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).