On Mon, Jul 29, 2019 at 10:40:59AM +0200, David Marchand wrote:
> On Sun, Jul 28, 2019 at 9:55 PM Thomas Monjalon <tho...@monjalon.net> wrote:
> > 25/07/2019 10:42, David Marchand:
> > > > > > 24/07/2019 17:20, Sean Morrissey:
> > > > On further investigation, the full fix involves
> > > > a change in the EAL command line parameter handling,
> > > > which is probably too risky for RC3.
> >
> > No way you change the command line parsing,
> > except the rte_option which was created for telemetry.
> > The history of this "simple" feature is already full
> > of hesitations which made me hesitate to merge.
> > Please, don't force me to dig in the code, otherwise
> > I will be tempted to do a big "clean-up".
> >
> > > > This revert will allow telemetry to function again,
> > > > but with the erroneous message still in place.
> > > > We will aim to fix in the next release.
> > >
> > > Might be good to look and revisit the rte_option api.
> >
>
> The patch on eal did not make any sense.
> I am for reverting it too.
>
Hi all,
quick look at it:
719 /*
720 * getopt didn't recognise the option, lets parse the
721 * registered options to see if the flag is valid
722 */
723 if (opt == '?') {
724 ret = rte_option_parse(argv[optind-1]);
725 if (ret == 0)
726 continue;
727
728 eal_usage(prgname);
729 ret = -1;
730 goto out;
731 }
If the --telemetry option is added to the EAL command line,
then this branch will not happen, which explains why the socket was not opened
on the lib side.
> About the real fix, I'd like to first see a description of the actual problem.
> Thanks.
>
>
> --
> David Marchand
Agreed, to add to this: was the build shared? It seems Stephen
encountered errors with RTE_INIT of DPDK libs not being executed in
shared builds, which could explain why everything would seem fine, but
the rte_option would not be registered, making the parsing error appear.
--
Gaëtan Rivet
6WIND
