Dave, Thanks for your explanation! In my opinion, it depends on what the "is_mp_safe" flag actually means. If all the functions are actually thread-safe and these barrier synchronization calls are required mainly for debugging, then I suggest the following:
#if CLIB_DEBUG > 0 if (!c->is_mp_safe) vlib_worker_thread_barrier_sync (vm); #endif c_error = c->function (vm, si, c); #if CLIB_DEBUG > 0 if (!c->is_mp_safe) vlib_worker_thread_barrier_release (vm); #endif or.... all these barrier synchronization calls must be moved into appropriate functions: c_error = c->function (vm, si, c, sync); Regards, Aleksander On Thu, Oct 31, 2019 at 10:27 PM, Dave Barach wrote: > > > > 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 > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14453): https://lists.fd.io/g/vpp-dev/message/14453 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] -=-=-=-=-=-=-=-=-=-=-=-
