Dave,
Couldn’t have explained it better! Thanks much!
Given that most CPU’s are 2+ cores, it should be okay but, you say “Note that
most debug CLI commands are not marked thread-safe”
Does it mean, it might they would still revert to a single-core like operation?
Thanks!
--
Regards,
Balaji.
From: "Dave Barach (dbarach)" <dbar...@cisco.com>
Date: Thursday, October 31, 2019 at 12:27 PM
To: "Balaji Venkatraman (balajiv)" <bala...@cisco.com>, "vpp-dev@lists.fd.io"
<vpp-dev@lists.fd.io>
Subject: RE: [vpp-dev] event-logger output format
Two cases: in single-core operation, debug CLI commands change the NDR / max
throughput. A single “format” call might cost as many clock cycles as
processing 50 packets. If the one and only core is busy printing something,
it’s not processing packets.
In multi-core operation, CLI commands typically don’t change the NDR / max
throughput numbers so long as they are marked thread_safe. Examples include
“show run.” Note that most debug CLI commands are not marked thread-safe.
I think that folks will complain early and often if we start printing
disclaimers every time vpp executes a non-thread-safe debug CLI command.
It wouldn’t be hard to count and [eventually] report non-thread-safe debug CLI
commands. All such barrier sync calls originate in one place, in src/vlib/cli.c:
if (!c->is_mp_safe)
vlib_worker_thread_barrier_sync (vm);
c_error = c->function (vm, si, c);
if (!c->is_mp_safe)
vlib_worker_thread_barrier_release (vm);
What do people think?
Thanks... Dave
From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Balaji Venkatraman
via Lists.Fd.Io
Sent: Thursday, October 31, 2019 12:21 PM
To: Aleksander Djuric <aleksander.dju...@gmail.com>; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] event-logger output format
Do you think it would be prudent to publish a ‘warning’ message on its impact
on packet forwarding when this cmd is used?
Thanks!
--
Regards,
Balaji.
From: <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> on behalf of Aleksander
Djuric <aleksander.dju...@gmail.com<mailto:aleksander.dju...@gmail.com>>
Date: Thursday, October 31, 2019 at 8:07 AM
To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>"
<vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] event-logger output format
Hi Dave, Thanks!
Now it looks like this:
> show event-logger [all] [<nnn>] [delta|no-delta|date-time]
Updated patch:
https://gerrit.fd.io/r/c/vpp/+/23146
On Thu, Oct 31, 2019 at 04:47 PM, Dave Barach wrote:
Yes, we see things differently. I never look at elog data in the debug CLI. I
save the data and deal with it offline. See
https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html. We
often use elog buffer sizes measured in millions of events. The offline tools
are happy to deal with 1e7 events.
Packet processing comes to a screeching halt while the “show event-logger”
debug CLI command runs. If folks decide that it’s worth trying to use the “show
event-logger” debug CLI on a regular basis, the first step should be to make
and mark the debug CLI command thread-safe. At least when using one or more
worker threads, packet processing won’t stop in its tracks for the duration...
I would prefer something of the form “show event-logger ... [full-timestamp]”
to request date/hms/msusns timestamps, and I would prefer the delta format I
described to tagging each event with a full timestamp. Maybe add
“[delta|no-delta]” qualifier keywords to the debug CLI command.
FWIW... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14442): https://lists.fd.io/g/vpp-dev/message/14442
Mute This Topic: https://lists.fd.io/mt/40103349/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
