25/07/2019 10:42, David Marchand: > > > > 24/07/2019 17:20, Sean Morrissey: > > > > > This reverts commit debacba0297fbe214b4185a9791e6a9fdf6642ba. > > > > > > > > > > Reverting this patch as it currently breaks the initialization of > > > > > telemetry, more investigation is ongoing to fix the issue for the > > > > > printed error message for unrecognized argument. > > > > > > > > > > Signed-off-by: Sean Morrissey <sean.morris...@intel.com> > > > > > > > > It's very disapointing. > > > > Did you or the reviewer tested the previous patch? > > > > > > > > The reporter of the bug tested this and verified functionality and > > > > closed the internal bug.> > > > > > > > > So the reverted commit is supposed to work? > > > I won't apply this revert until I fully understand what happens. > > > > The patch that I sent up was to remove an "unrecognized > > option telemetry" warning message, which the patch > > removed and was tested to ensure the message was removed. > > Further testing, after the patch was sent up,
So the patch was sent and reviewed without testing the functionality. > > revealed that the unix domain socket, > > which is required by telemetry consumers, > > was no longer being created, > > rendering the telemetry functionality non-functional. Why this socket is not created? How is it related to the option parsing? > > 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.
