Add enhanced SwssStats for comprehensive profiling by yutongzhang-microsoft · Pull Request #4434 · sonic-net/sonic-swss

yutongzhang-microsoft · 2026-04-03T03:06:15Z

What I did

Added SwssStats, a lightweight per-table statistics collector for orchagent. It tracks operation counts written to COUNTERS_DB every second via a background thread, with no impact on the main processing path.

Metrics tracked per table:

Field	Description
`SET`	Number of SET tasks received
`DEL`	Number of DEL tasks received
`COMPLETE`	Number of tasks successfully processed
`ERROR`	Number of tasks that resulted in an error

Redis schema:

   SWSS_STATS:<table_name>
     SET       <count>
     DEL       <count>
     COMPLETE  <count>
     ERROR     <count>

Why I did it

The existing OrchStats (PR #2812) only tracks SET/DEL counts at the Orch level. There is no lightweight way to observe:

Which tables have pending/unprocessed tasks
Whether tasks are completing successfully or hitting errors
Per-table throughput in production deployments

SwssStats fills this gap with minimal overhead, making it easier to diagnose bottlenecks and processing anomalies in large-scale deployments without relying on the verbose swss.rec recording.

Design

Lock-free hot path: recordTask() and recordComplete() use std::atomic operations. The mutex is only held briefly by the background writer thread when snapshotting counters.
Version-based dirty tracking: Each TableStats has an atomic version counter incremented on every update. The writer thread skips Redis writes for tables with no changes since the last flush.
Deferred DB connection: DBConnector(COUNTERS_DB) is created inside writerThread() rather than the constructor, so singleton initialization during orchagent's early startup (bake phase) does not trigger Redis access before the DB is ready.
Stable references: Uses std::map instead of unordered_map so references returned by getOrCreateStats() remain valid after subsequent inserts (unordered_map can rehash and invalidate references).
Clean shutdown: Destructor uses condition_variable::notify_all() to wake the writer thread immediately instead of waiting up to 1 second.

How I verified it

Unit tests (tests/mock_tests/swssstats_ut.cpp):

Basic counter increments for SET, DEL, COMPLETE, ERROR
Unknown ops are silently ignored
Zero snapshot returned for unknown tables
Multiple tables are tracked independently
Thread safety: 8 concurrent threads x 1000 ops each, verified with TSan

Manual verification in docker-sonic-vs:

docker run --privileged -d --name vs docker-sonic-vs:<tag>
docker exec vs mkdir -p /zmq_swss
docker exec vs supervisorctl start orchagent

# Check stats after orchagent starts
yutongzhang@yutongzhang-dev-vm-2:~$ docker exec vs redis-cli -n 2 keys "SWSS_STATS*"
SWSS_STATS:SCHEDULER
SWSS_STATS:DSCP_TO_TC_MAP
SWSS_STATS:MAP_PFC_PRIORITY_TO_QUEUE
SWSS_STATS:PORT_QOS_MAP
SWSS_STATS:WRED_PROFILE
SWSS_STATS:TC_TO_PRIORITY_GROUP_MAP
SWSS_STATS:DEVICE_METADATA
SWSS_STATS:PORT_TABLE
SWSS_STATS:TC_TO_QUEUE_MAP

yutongzhang@yutongzhang-dev-vm-2:~$ docker exec vs redis-cli -n 2 hgetall "SWSS_STATS:DSCP_TO_TC_MAP"
SET
1
DEL
0
COMPLETE
0
ERROR
0

Physical testbed verification:

Built the latest SONiC image using sonic-buildimage PR #26924
Downloaded build artifacts and deployed on a physical testbed
Verified SwssStats counters are correctly populated on real hardware

admin@bjw2-can-7260-12:~$ redis-cli -n 2 keys "SWSS_STATS*"
 1) "SWSS_STATS:PORTCHANNEL_INTERFACE"
 2) "SWSS_STATS:PORTCHANNEL"
 3) "SWSS_STATS:NEIGH_TABLE"
 4) "SWSS_STATS:CABLE_LENGTH"
 5) "SWSS_STATS:BUFFER_POOL"
 6) "SWSS_STATS:MAP_PFC_PRIORITY_TO_QUEUE"
 7) "SWSS_STATS:ACL_TABLE"
 8) "SWSS_STATS:TC_TO_QUEUE_MAP"
 9) "SWSS_STATS:DSCP_TO_TC_MAP"
10) "SWSS_STATS:BUFFER_PROFILE"
11) "SWSS_STATS:LAG_TABLE"
12) "SWSS_STATS:ROUTE_TABLE"
13) "SWSS_STATS:BUFFER_QUEUE_TABLE"
14) "SWSS_STATS:PORT_QOS_MAP"
15) "SWSS_STATS:BUFFER_QUEUE"
16) "SWSS_STATS:PORTCHANNEL_MEMBER"
17) "SWSS_STATS:LAG_MEMBER_TABLE"
18) "SWSS_STATS:BUFFER_PG"
19) "SWSS_STATS:WRED_PROFILE"
20) "SWSS_STATS:TC_TO_PRIORITY_GROUP_MAP"
21) "SWSS_STATS:FLEX_COUNTER_TABLE"
22) "SWSS_STATS:BUFFER_PROFILE_TABLE"
23) "SWSS_STATS:TUNNEL_DECAP_TABLE"
24) "SWSS_STATS:INTF_TABLE"
25) "SWSS_STATS:TUNNEL_DECAP_TERM_TABLE"
26) "SWSS_STATS:SCHEDULER"
27) "SWSS_STATS:LOOPBACK_INTERFACE"
28) "SWSS_STATS:PORT_TABLE"
29) "SWSS_STATS:BUFFER_PG_TABLE"
30) "SWSS_STATS:BGP_DEVICE_GLOBAL"
31) "SWSS_STATS:CRM"
32) "SWSS_STATS:FEATURE"
33) "SWSS_STATS:BUFFER_POOL_TABLE"
34) "SWSS_STATS:PORT"
35) "SWSS_STATS:COPP_TABLE"
36) "SWSS_STATS:SWITCH_TABLE"
37) "SWSS_STATS:QUEUE"
38) "SWSS_STATS:PFC_WD"
39) "SWSS_STATS:DEVICE_METADATA"

admin@bjw2-can-7260-12:~$ redis-cli -n 2 hgetall "SWSS_STATS:ROUTE_TABLE"
1) "SET"
2) "15390"
3) "DEL"
4) "14"
5) "COMPLETE"
6) "15404"
7) "ERROR"
8) "0"

Performance

CPU: counter updates use memory_order_relaxed atomics - negligible overhead on the hot path
Memory: ~80 bytes per tracked table (5 x atomic<uint64_t>)
Redis writes: at most once per second per changed table, skipped entirely if no updates

mssonicbld · 2026-04-03T03:06:25Z

/azp run

azure-pipelines · 2026-04-03T03:06:36Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-04-03T03:09:01Z

/azp run

azure-pipelines · 2026-04-03T03:09:12Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-04-15T07:28:59Z

/azp run

azure-pipelines · 2026-04-15T07:29:10Z

Azure Pipelines successfully started running 1 pipeline(s).

What I did: - Added SwssStats class with enhanced statistics collection - Supports operation counters (SET/DEL/COMPLETED/ERROR) - Tracks latency metrics (min/max/avg/total in microseconds) - Monitors queue depth (current/max) - Uses lock-free atomic operations for zero performance impact - Background thread writes to Redis COUNTERS_DB every 1 second Why I did it: - Original OrchStats (PR sonic-net#2812) only tracks SET/DEL counts - Need comprehensive performance monitoring for production debugging - Lightweight alternative to swss.rec with minimal CPU/disk overhead - Essential for analyzing bottlenecks in large-scale deployments How I verified it: - Follows OrchStats design pattern from PR sonic-net#2812 - All statistics accessible via Redis COUNTERS_DB - Query tools provided (query_stats.sh, monitor_stats.py) Details: - Table name: SWSS_STATS_TABLE (vs ORCH_STATS_TABLE) - 10 metrics per table vs 2 in OrchStats - Performance: <0.1% CPU, ~1KB memory per table Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com>

Simplified the statistics implementation to be self-contained: Changes: - Removed complex latency tracking (can be added later if needed) - Removed queue depth monitoring - Simplified API: recordTask(table, op), recordComplete(), recordError() - Reduced code size by ~90 lines - No dependency on any existing stats implementation Core features retained: - Track SET/DEL operations per table - Monitor task completion count - Track errors - Atomic operations for thread safety - Background thread updates Redis every 1 second - Writes to COUNTERS_DB SWSS_STATS table This is a clean, minimal implementation that can work independently. Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com>

- Fix data race: change m_running from bool to std::atomic<bool> - Fix reference invalidation: replace unordered_map with std::map so references returned by getOrCreateStats() remain stable after subsequent inserts (unordered_map can rehash, invalidating refs) - Fix memory ordering: use memory_order_release on version.fetch_add() and memory_order_acquire on version.load() in writer thread, with memory_order_relaxed on counter updates to match the documented happens-before relationship - Fix shutdown latency: replace sleep_for() with condition_variable wait_for() so destructor wakes the writer thread immediately - Fix gSwssStatsRecord: change to std::atomic<bool> to prevent data race if toggled at runtime; add extern declaration in swssstats.h - Remove SWSS_LOG_ENTER() from hot-path record* methods - Wire up recordComplete(): Consumer::drain() now counts tasks removed from m_toSync and calls recordComplete() so the COMPLETE counter is actually populated - Add count parameter to recordComplete/recordError for batch updates - Fix Makefile.am: add missing space before backslash continuation on notifications.cpp line Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com>

mssonicbld · 2026-04-15T07:35:11Z

/azp run

azure-pipelines · 2026-04-15T07:35:23Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-04-15T07:48:17Z

/azp run

azure-pipelines · 2026-04-15T07:48:27Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-04-15T07:50:53Z

/azp run

azure-pipelines · 2026-04-15T07:51:05Z

Azure Pipelines successfully started running 1 pipeline(s).

- Add getCounters() method to SwssStats for counter inspection in tests and diagnostics (returns CounterSnapshot struct with SET/DEL/COMPLETE/ERROR) - Add swssstats_ut.cpp with gtest coverage: * Basic counter increment tests (SET, DEL, COMPLETE, ERROR) * Unknown op is silently ignored * Default count=1 for recordComplete/recordError * Zero snapshot for unknown tables * Multiple tables are independent * Thread-safety: 8 concurrent threads with 1000 ops each, no data race * Mixed concurrent ops (recordTask + recordComplete + recordError) * Destructor/shutdown fast-path sanity check - Wire swssstats_ut.cpp and swssstats.cpp into tests/mock_tests/Makefile.am Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com>

'swss::FieldValueTuple' is declared as a typedef in swsscommon's table.h, so it cannot be forward-declared with 'class'. The forward declaration was introduced when dumpStats() was a class member. Fix by: - Remove 'class FieldValueTuple' forward declaration from swssstats.h - Move dumpStats() out of the class and make it a file-local static function in swssstats.cpp (it was already private with no external callers) - Move TableStats struct to public section so the file-local static function can access it without a friend declaration Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com>

mssonicbld · 2026-04-15T07:51:59Z

/azp run

azure-pipelines · 2026-04-15T07:52:10Z

Azure Pipelines successfully started running 1 pipeline(s).

orch.cpp now calls SwssStats::getInstance() and SwssStats::recordTask/ recordComplete, so every build target that links orch.cpp must also link swssstats.cpp. Affected Makefiles: - orchagent/p4orch/tests/Makefile.am (p4orch_tests) - cfgmgr/Makefile.am (COMMON_ORCH_SOURCE shared by vlanmgrd, teammgrd, etc.) tests/mock_tests/Makefile.am already has swssstats.cpp from the previous commit. Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

mssonicbld · 2026-04-15T08:08:28Z

/azp run

azure-pipelines · 2026-04-15T08:08:38Z

Azure Pipelines successfully started running 1 pipeline(s).

Add swssstats.cpp to tests_intfmgrd_SOURCES and tests_teammgrd_SOURCES in tests/mock_tests/Makefile.am. Both targets link orch.cpp which now references SwssStats symbols. Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

mssonicbld · 2026-04-15T08:40:05Z

/azp run

azure-pipelines · 2026-04-15T08:40:17Z

Azure Pipelines successfully started running 1 pipeline(s).

tests_nbrmgrd links orchagent/orch.cpp which references SwssStats, but swssstats.cpp was not listed in tests_nbrmgrd_SOURCES, causing undefined reference errors at link time. Add swssstats.cpp to fix the build. Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

mssonicbld · 2026-04-16T02:41:53Z

/azp run

azure-pipelines · 2026-04-16T02:41:59Z

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

Sync with master introduced a merge conflict resolution error in Consumer::drain(): doTask() was called twice and the stats recording if-block was missing its closing brace, causing the try/catch to be nested inside it. This broke the build with 'qualified-id in declaration before token' errors. Fix: move try/catch to wrap the single doTask() call, and place the SwssStats recordComplete() block after the try/catch. Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

mssonicbld · 2026-04-17T06:10:48Z

/azp run

azure-pipelines · 2026-04-17T06:11:00Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-04-21T02:57:59Z

/azp run

azure-pipelines · 2026-04-21T02:58:09Z

Azure Pipelines successfully started running 1 pipeline(s).

The SwssStats singleton is first created when addToSync() is called during early orchagent initialization (bake phase). At that point, calling DBConnector("COUNTERS_DB", 0) in the constructor triggers a synchronous Redis GET via swsscommon that returns 0 values, causing a std::runtime_error (waitForGetResponse) and orchagent crash (SIGABRT). Fix: move m_db and m_table creation from the constructor into the start of writerThread(), where orchagent is fully initialized and COUNTERS_DB is accessible. Added try/catch so a connection failure disables Redis writes without crashing the process. Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

mssonicbld · 2026-04-21T03:01:03Z

/azp run

azure-pipelines · 2026-04-21T03:01:13Z

Azure Pipelines successfully started running 1 pipeline(s).

Copilot

Pull request overview

This PR introduces a new SwssStats collector intended to provide lightweight, always-on orchestration statistics exported into COUNTERS_DB, and wires it into orchagent’s task ingestion (addToSync) and processing (drain) flow. It also updates build/test wiring so the new stats implementation is compiled into relevant binaries and adds a mock-test unit test file.

Changes:

Added SwssStats singleton with a background writer thread that periodically writes per-table counters to COUNTERS_DB.
Integrated stats recording into ConsumerBase::addToSync() (SET/DEL) and Consumer::drain() (COMPLETE).
Added/updated mock tests and Makefile sources to compile/link the new implementation across existing unit-test binaries and components.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 13 comments.

Show a summary per file

File	Description
tests/mock_tests/swssstats_ut.cpp	Adds unit tests for counter correctness and concurrency behavior.
tests/mock_tests/Makefile.am	Builds `swssstats_ut.cpp` and links `swssstats.cpp` into test binaries.
orchagent/swssstats.h	Declares the `SwssStats` API and internal counter storage.
orchagent/swssstats.cpp	Implements the singleton, counter updates, and Redis writer thread.
orchagent/orch.cpp	Hooks stats into task enqueue and drain paths; defines `gSwssStatsRecord`.
orchagent/Makefile.am	Adds `swssstats.cpp` to orchagent build.
cfgmgr/Makefile.am	Links `swssstats.cpp` alongside `orch.cpp` in common sources.
orchagent/p4orch/tests/Makefile.am	Links `swssstats.cpp` into p4orch unit tests.

Copilot · 2026-04-21T07:03:53Z

 using namespace swss;

 int gBatchSize = 0;
+std::atomic<bool> gSwssStatsRecord(true);  // Enable SwssStats by default


gSwssStatsRecord is enabled by default, but there is no mechanism in this PR to toggle it at runtime (no config/env/CLI hook), and it introduces extra per-task work and a background writer thread. Consider defaulting this to disabled or wiring it to a configuration option so operators can turn it on only when needed.

Copilot · 2026-04-21T07:03:53Z

+    // m_running uses atomic to avoid data race between main and writer threads
+    std::atomic<bool> m_running;
+    uint32_t m_interval_sec;
+    std::unique_ptr<std::thread> m_thread;
+    std::mutex m_mutex;
+    // m_cv allows the destructor to wake the writer thread immediately
+    std::condition_variable m_cv;
+
+    std::shared_ptr<swss::DBConnector> m_db;
+    std::unique_ptr<swss::Table> m_table;
+
+    // std::map is used instead of unordered_map: map iterators and references
+    // to existing elements remain valid after new insertions, which is required
+    // because recordTask() holds a reference after releasing m_mutex.
+    std::map<std::string, TableStats> m_stats;
+
+    SwssStats(uint32_t interval = 1);
+
+    // Returns a stable reference to the TableStats for the given table,
+    // creating it if it does not exist. Safe to use after m_mutex is released
+    // because std::map never invalidates existing element references.
+    TableStats& getOrCreateStats(const std::string &table_name);


The PR description claims “lock-free atomic operations for zero performance impact”, but the implementation takes m_mutex in every record*() call via getOrCreateStats() to access m_stats. Either adjust the PR description/expectations, or consider an approach that avoids a global mutex on the hot path (e.g., per-table cached pointer/reference, sharded maps, or thread-local aggregation).

Copilot · 2026-04-21T07:03:54Z

+    thread t1([s, &tbl]()
+    {
+        for (int i = 0; i < ops; i++) s->recordTask(tbl, "SET");
+    });
+    thread t2([s, &tbl]()
+    {
+        for (int i = 0; i < ops; i++) s->recordComplete(tbl);
+    });
+    thread t3([s, &tbl]()


The lambda for t1 uses the local variable ops but does not capture it (capture list is [s, &tbl]). This will not compile; capture ops by value (or use [=]).

Suggested change

thread t1([s, &tbl]()

{

for (int i = 0; i < ops; i++) s->recordTask(tbl, "SET");

});

thread t2([s, &tbl]()

{

for (int i = 0; i < ops; i++) s->recordComplete(tbl);

});

thread t3([s, &tbl]()

thread t1([s, &tbl, ops]()

{

for (int i = 0; i < ops; i++) s->recordTask(tbl, "SET");

});

thread t2([s, &tbl, ops]()

{

for (int i = 0; i < ops; i++) s->recordComplete(tbl);

});

thread t3([s, &tbl, ops]()

Copilot · 2026-04-21T07:03:54Z

+    thread t2([s, &tbl]()
+    {
+        for (int i = 0; i < ops; i++) s->recordComplete(tbl);
+    });


The lambda for t2 uses the local variable ops but does not capture it (capture list is [s, &tbl]). This will not compile; capture ops by value (or use [=]).

Copilot · 2026-04-21T07:03:54Z

+    thread t1([s, &tbl]()
+    {
+        for (int i = 0; i < ops; i++) s->recordTask(tbl, "SET");
+    });
+    thread t2([s, &tbl]()
+    {
+        for (int i = 0; i < ops; i++) s->recordComplete(tbl);
+    });
+    thread t3([s, &tbl]()


The lambda for t3 uses the local variable ops but does not capture it (capture list is [s, &tbl]). This will not compile; capture ops by value (or use [=]).

Suggested change

thread t1([s, &tbl]()

{

for (int i = 0; i < ops; i++) s->recordTask(tbl, "SET");

});

thread t2([s, &tbl]()

{

for (int i = 0; i < ops; i++) s->recordComplete(tbl);

});

thread t3([s, &tbl]()

thread t1([s, &tbl, ops]()

{

for (int i = 0; i < ops; i++) s->recordTask(tbl, "SET");

});

thread t2([s, &tbl, ops]()

{

for (int i = 0; i < ops; i++) s->recordComplete(tbl);

});

thread t3([s, &tbl, ops]()

Copilot · 2026-04-21T07:03:55Z

@@ -581,6 +592,13 @@ void Consumer::drain()
            SWSS_LOG_ERROR("Exception caught: type=unknown, table=%s",
                           getName().c_str());
        }
+        if (gSwssStatsRecord && size_before > 0)
+        {
+            size_t size_after = m_toSync.size();
+            uint64_t completed = (size_before > size_after) ? (size_before - size_after) : 0;
+            if (completed > 0)
+                SwssStats::getInstance()->recordComplete(getTableName(), completed);
+        }


recordComplete() is called even when doTask() throws and the drain path enters one of the catch blocks. That can inflate “COMPLETE” counts during failures. Consider recording completion only on the success path (e.g., after doTask() returns normally), and use recordError() in the exception paths if you want ERROR to reflect task processing failures.

Copilot · 2026-04-21T07:03:56Z

+        threads.emplace_back([s, &tbl]()
+        {
+            for (int j = 0; j < ops_per_thread; j++)
+            {
+                s->recordTask(tbl, (j % 2 == 0) ? "SET" : "DEL");


In this lambda, ops_per_thread is used inside the body but is not captured (capture list is [s, &tbl]). This won’t compile. Capture ops_per_thread (and any other referenced locals) by value, or switch to [=] / [&, ops_per_thread] as appropriate.

Copilot · 2026-04-21T07:03:56Z

+// Return a fresh SwssStats instance with a very long flush interval so the
+// background writer never fires during tests, keeping tests fast and deterministic.
+static SwssStats* stats()
+{
+    // The singleton is reused across tests in the same process; that is fine
+    // because each test reads back only what it wrote, using unique table names.
+    return SwssStats::getInstance();


This helper/comment says it returns an instance with a long flush interval so the background writer never fires, but it always returns the singleton with the default interval (1s). Either update the comment to match reality, or add a test hook/config to disable the writer thread / change the interval for unit tests to keep them deterministic.

Copilot · 2026-04-21T07:03:56Z

+    // not yet be accessible (causes waitForGetResponse crash).
+    m_thread = make_unique<thread>(&SwssStats::writerThread, this);
+
+    SWSS_LOG_NOTICE("SwssStats initialized (interval: %d sec)", m_interval_sec);


SWSS_LOG_NOTICE("... %d ...", m_interval_sec) uses %d for m_interval_sec (a uint32_t). This can trigger format warnings or incorrect output on some platforms; use an unsigned format (%u) or a fixed-width macro like PRIu32.

Suggested change

SWSS_LOG_NOTICE("SwssStats initialized (interval: %d sec)", m_interval_sec);

SWSS_LOG_NOTICE("SwssStats initialized (interval: %u sec)", m_interval_sec);

Copilot · 2026-04-21T07:03:56Z

+#include "dbconnector.h"
+#include "table.h"
+#include "logger.h"
+#include <chrono>


This file uses unordered_map, piecewise_construct, and forward_as_tuple, but the required standard headers (<unordered_map>, <utility>, <tuple>) aren’t included. This may fail to compile depending on transitive includes; add the missing includes explicitly.

Suggested change

#include <chrono>

#include <chrono>

#include <tuple>

#include <unordered_map>

#include <utility>

Fixes identified in code review: - swssstats.cpp: add missing includes (<tuple>, <unordered_map>, <utility>) - swssstats.cpp: fix printf format specifier %d -> %u for uint32_t (line 29) - swssstats.cpp: only bump version counter when SET/DEL actually modifies a counter; unknown ops no longer cause spurious Redis writes - swssstats.h: add missing #include <cstdint> for uint32_t / uint64_t - swssstats_ut.cpp: fix lambda captures missing ops_per_thread / ops; lambdas now correctly capture all variables they reference - swssstats_ut.cpp: update stats() helper comment to reflect that it returns the default-interval singleton, not a special long-interval instance - orch.cpp: Consumer::drain() now calls recordError() in every catch block and only calls recordComplete() on the success path, preventing inflated COMPLETE counts when doTask() throws Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com>

mssonicbld · 2026-04-21T08:18:32Z

/azp run

azure-pipelines · 2026-04-21T08:18:43Z

Azure Pipelines successfully started running 1 pipeline(s).

r12f · 2026-04-22T04:58:44Z

+
+SwssStats::CounterSnapshot SwssStats::getCounters(const string &table_name)
+{
+    lock_guard<mutex> lock(m_mutex);


Rename the mutex. Make meaningful names

Changed to m_statsMutex

mssonicbld · 2026-04-22T08:36:39Z

/azp run

azure-pipelines · 2026-04-22T08:36:50Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2026-04-22T08:40:11Z

/azp run

azure-pipelines · 2026-04-22T08:40:23Z

Azure Pipelines successfully started running 1 pipeline(s).

Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com>

mssonicbld · 2026-04-22T08:46:52Z

/azp run

azure-pipelines · 2026-04-22T08:47:02Z

Azure Pipelines successfully started running 1 pipeline(s).

yutongzhang-microsoft and others added 3 commits April 15, 2026 15:34

yutongzhang-microsoft force-pushed the swss-stats-implementation branch from 3410bd9 to 0d75119 Compare April 15, 2026 07:35

yutongzhang-microsoft and others added 2 commits April 15, 2026 15:51

yutongzhang-microsoft force-pushed the swss-stats-implementation branch from 9d1640a to f6357c7 Compare April 15, 2026 07:51

yutongzhang-microsoft force-pushed the swss-stats-implementation branch from eb61427 to bbe820f Compare April 21, 2026 03:00

yutongzhang-microsoft marked this pull request as ready for review April 21, 2026 06:56

yutongzhang-microsoft requested a review from prsunny as a code owner April 21, 2026 06:56

Copilot AI review requested due to automatic review settings April 21, 2026 06:56

Copilot started reviewing on behalf of yutongzhang-microsoft April 21, 2026 06:57 View session

yutongzhang-microsoft requested review from Pterosaur and r12f April 21, 2026 06:58

Copilot AI reviewed Apr 21, 2026

View reviewed changes

yutongzhang-microsoft mentioned this pull request Apr 21, 2026

[test] Build with ComponentStats-based SwssStats (PR sonic-swss#4516 + sonic-swss-common#1180) sonic-net/sonic-buildimage#26924

Closed

r12f reviewed Apr 22, 2026

View reviewed changes

yutongzhang-microsoft force-pushed the swss-stats-implementation branch from 2bdad89 to 1061df3 Compare April 22, 2026 08:39

Rename m_mutex to m_statsMutex for clarity

132510e

Signed-off-by: Yutong Zhang <yutongzhang@microsoft.com>

yutongzhang-microsoft force-pushed the swss-stats-implementation branch from 1061df3 to 132510e Compare April 22, 2026 08:46

	SWSS_LOG_NOTICE("SwssStats initialized (interval: %d sec)", m_interval_sec);
	SWSS_LOG_NOTICE("SwssStats initialized (interval: %u sec)", m_interval_sec);

-#include <chrono>
+#include <chrono>
+#include <tuple>
+#include <unordered_map>
+#include <utility>

Conversation

yutongzhang-microsoft commented Apr 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What I did

Why I did it

Design

How I verified it

Performance

Uh oh!

mssonicbld commented Apr 3, 2026

Uh oh!

azure-pipelines Bot commented Apr 3, 2026

Uh oh!

mssonicbld commented Apr 3, 2026

Uh oh!

azure-pipelines Bot commented Apr 3, 2026

Uh oh!

mssonicbld commented Apr 15, 2026

Uh oh!

azure-pipelines Bot commented Apr 15, 2026

Uh oh!

mssonicbld commented Apr 15, 2026

Uh oh!

azure-pipelines Bot commented Apr 15, 2026

Uh oh!

mssonicbld commented Apr 15, 2026

Uh oh!

azure-pipelines Bot commented Apr 15, 2026

Uh oh!

mssonicbld commented Apr 15, 2026

Uh oh!

azure-pipelines Bot commented Apr 15, 2026

Uh oh!

mssonicbld commented Apr 15, 2026

Uh oh!

azure-pipelines Bot commented Apr 15, 2026

Uh oh!

mssonicbld commented Apr 15, 2026

Uh oh!

azure-pipelines Bot commented Apr 15, 2026

Uh oh!

mssonicbld commented Apr 15, 2026

Uh oh!

azure-pipelines Bot commented Apr 15, 2026

Uh oh!

mssonicbld commented Apr 16, 2026

Uh oh!

azure-pipelines Bot commented Apr 16, 2026

Uh oh!

mssonicbld commented Apr 17, 2026

Uh oh!

azure-pipelines Bot commented Apr 17, 2026

Uh oh!

mssonicbld commented Apr 21, 2026

Uh oh!

azure-pipelines Bot commented Apr 21, 2026

Uh oh!

mssonicbld commented Apr 21, 2026

Uh oh!

azure-pipelines Bot commented Apr 21, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

yutongzhang-microsoft commented Apr 3, 2026 •

edited

Loading