Documents: Debug Framework Design Spec #398
Conversation
* A framework that allows components to register and dump running snapshots of component internals using dump routines. * Handle assert conditions to collect more info. Signed-off-by: Anil Sadineni anil.sadineni@broadcom.com
| - Within the function, dump the information into a string buffer and use a macro `SWSS_DEBUG_PRINT`. Macro will further process the information based on intended framework action. Wrap the function that uses multiple invocations of `SWSS_DEBUG_PRINT` with `SWSS_DEBUG_PRINT_BEGIN` and `SWSS_DEBUG_PRINT_END`. | ||
| - Handle KeyOpFieldsValuesTuple as argument. Arguments like dumpType and pass thru arguments that instruct the level of info dump ( short summary/specific info/filtered output/full info) should be handled by components. These arguments are opaque to framework. Additional optional arguments like output location and post-actions are for the framework consumption. | ||
| - Interpreting arguments is at discretion of components. Components may choose to dump same info for all trigger types ignoring input arguments. | ||
| - Dump routines registered with framework should be thread safe. Necessary synchronization needs to be ensured. |
There was a problem hiding this comment.
orchagent is single thread application, it has no lock. how are you going to make the dump routine to be thread safe?
|
|
||
|
|
||
| **Implementation brief** | ||
| Framework will be implemented in C++ as a class in SWSS namespace. |
There was a problem hiding this comment.
how to open source project which are not written in C++, for example dhcp relay which is written in C, or go such as telemetry component, or python program?
There was a problem hiding this comment.
Good question. For python programs SWIG will help us. Check pyext folder for interface file definition.
For C, yes we need to write wrapper functions.
| |-------------------------------|-------------------------------------------------------------------------------| | ||
| |show debug all | This command will invoke dump routines for all components with default action | | ||
| |show debug < component > | This command will invoke dump routine for specific component | | ||
| |show debug actions < options > | This command will display the configured framework actions | |
There was a problem hiding this comment.
how do we know all the component that has such debug capability? is there a command for that?
There was a problem hiding this comment.
component owner trying to debug his component will enter component name so that the trigger to dump will be specific to the component specified. If the admin is trying to collect debug information and has no knowledge of registered components he may consider show debug all.
If its an engineer but not component owner who is trying to figure out the registered components he can query Redis DB for the registered component list using redis-cli and then proceed with the trigger.
| |show debug actions < options > | This command will display the configured framework actions | | ||
|
|
||
| ### 3.3.2 Debug/Error Interface counters | ||
| show interfaces pktdrop is added to display debug/error counters for all interfaces. |
There was a problem hiding this comment.
how is this different from the portstat command line currently we have?
There was a problem hiding this comment.
The initial thought was to fetch more errors and counters from the asic but this is not a framework item and very asic dependent hence dropped it. Shall remove in next version.
These changes along with changes in sonic-utilities are needed to test the framework The code is inline with design from: sonic-net/SONiC#398
Signed-off-by: Anil Sadineni anil.sadineni@broadcom.com