local ARS#7
Open
VladimirKuk wants to merge 341 commits into
Open
Conversation
apannerselva
force-pushed
the
mrvl-local-ARS
branch
3 times, most recently
from
November 3, 2025 18:04
4466fb2 to
f4fe7ae
Compare
apannerselva
force-pushed
the
mrvl-local-ARS
branch
from
November 20, 2025 08:39
f4fe7ae to
ee3f102
Compare
What I did Wrapping with log::log_enabled!(log::Level::Debug) avoids the cost of building log output unless Debug is enabled. Changing print_otel_metrics() to Debug level prevents noisy logs in normal operation; it only shows up when debugging. Removing print_to_console simplifies config and relies solely on log levels to control output. Why I did it Avoids the cost of building log output unless Debug is enabled.
…ast router interface table entries. Signed-off-by: mint570 <runmingwu@google.com>
[P4Orch] Implement functions to perform state verification for multicast router interface table entries.
What I did Only set certain CA to PA attributes if they are valid for a given mapping type Why I did it Some SAI attributes are only valid for privatelink and some are only valid for non-privatelink. This is enforced by the SAI metadata layer, so add this check in orchagent to prevent crashes.
…net#4197) What I did The main function exits as soon as any actor terminates. Why I did it Otel actor may terminate due to failed to connect the otel collector. In the previous behavior, the main function will not exit because it's waiting for all actor terminating.
Signed-off-by: mint570 <runmingwu@google.com>
[P4Orch] Implement functions to add route entries that assign multicast.
…entries. Signed-off-by: mint570 <runmingwu@google.com>
[P4Orch] Implement functions for adding and deleting multicast replication entries.
Signed-off-by: mint570 <runmingwu@google.com>
[P4Orch] Implement functions for updating multicast replication entries.
Add unit tests for CounterNameMapUpdater to verify that counter name maps are correctly written to COUNTERS_DB regardless of HFT (High Frequency Telemetry) support. Tests cover: QUEUE counter maps without HFT support Single counter name map operations These tests verify the fix from sonic-net#3967 that removed the outer 'if (gHFTOrch)' check which was preventing counter registration on platforms without HFT support.
…et#4064) * NOS-467: Fix MACsec unconfigure failures due to time out (sonic-net#214) ### Summary NOS-467 tracks sporadic MACsec cleanup failures where `wpa_cli interface_remove` either times out or returns `FAIL`, causing `macsecmgrd` to surface spurious Task `PORT` `SET` failures and sometimes leave MACsec state in a partially torn-down state. Below are some error messages seen before the test failure `humm120-dut WARNING macsec#macsecmgrd: :- unconfigureMACsec: Disable MACsec fail : /sbin/wpa_cli -g /var/run/Ethernet0 interface_remove Ethernet0 : 'INTERFACE_REMOVE Ethernet0' command timed out humm120-dut WARNING macsec#macsecmgrd: :- disableMACsec: Cannot stop MKA session on the port 'Ethernet0' humm120-dut WARNING macsec#macsecmgrd: :- doTask: Task PORT - SET fail humm120-dut NOTICE macsec#macsecmgrd: :- unconfigureMACsec: interface_remove for port 'Ethernet8' reported error 'Wpa_cli command : /sbin/wpa_cli -g /var/run/Ethernet8 interface_remove Ethernet8 -> FAIL ` ### Changes 1. **MACsecMgr::unconfigureMACsec: retry and best-effort semantics** * Replace the single `wpa_cli_exec_and_check(..., "interface_remove", port_name)` call with a small retry loop: * Introduce `MAX_INTERFACE_REMOVE_RETRIES = 3`. * For each attempt: * Call `interface_remove` via `wpa_cli_exec_and_check`. * In the `catch (std::runtime_error &e)` path, inspect the error string: * If it contains `"-> FAIL"`, treat this as **best-effort success** – in practice this means the interface is already gone from `wpa_supplicant`, which is equivalent to a successful unconfigure from macsecmgr's perspective. `humm120-dut NOTICE macsec#macsecmgrd: :- unconfigureMACsec: interface_remove for port 'Ethernet8' reported error 'Wpa_cli command : /sbin/wpa_cli -g /var/run/Ethernet8 interface_remove Ethernet8 -> FAIL#012'; treating MACsec unconfigure as best-effort success` * If it contains `"command timed out"`: * Retry up to `MAX_INTERFACE_REMOVE_RETRIES` times. * Between retries, log a WARN message and sleep 10 seconds using `std::this_thread::sleep_for(std::chrono::seconds(10))`. * After the last retry, log a NOTICE and treat the overall unconfigure as **best-effort success**. The caller will still invoke `stopWPASupplicant()` which tears down the process and its interfaces. * For any other error string, log a WARN and return `false` (preserving the existing behavior for unexpected failures). * On a completely successful `interface_remove`, simply fall through the loop and return `true` at the end. ### Rationale * Field logs show intermittent `wpa_cli interface_remove` timeouts and `FAIL` responses during MACsec teardown, which currently bubble up as hard failures in `MACsecMgr::unconfigureMACsec`. This can cause Task `PORT` `SET` failures even though the underlying state has been effectively cleaned up (or will be cleaned up by killing `wpa_supplicant`). * By adding retries and best-effort semantics specifically for these two known benign failure modes, we avoid unnecessary churn in the MACsec pipeline while still treating all other errors as real failures. ### Testing * Built and exercised the corresponding change in `private-sonic-buildimage` against a MACsec-capable DUT (humm120) where `interface_remove` timeouts were observed. * Rebuilt `swss` and deployed to the DUT; MACsec teardown no longer surfaces spurious Task `PORT` `SET` failures when `interface_remove` times out or returns `FAIL` from `wpa_cli`. Signed-off-by: rajshekhar <rajshekhar@nexthop.ai> * MACsec: refine interface_remove retry handling Signed-off-by: rajshekhar <rajshekhar@nexthop.ai>
…ries. Signed-off-by: mint570 <runmingwu@google.com>
[P4Orch] Implement functions to drain multicast replication table entries.
What I did Remove deprecated parameters. Why I did it The parameter, print_to_console, has been removed, but the CI will not run any bench program, so this error was ignored.
…n table entries. Signed-off-by: mint570 <runmingwu@google.com>
[P4Orch] Implement functions to verify state for multicast replication table entries.
Signed-off-by: Rustiqly <rustiqly@users.noreply.github.com>
What I did Added support for polling PORT PHY attributes using the flex counter infrastructure. Following changes are added in swss to support this feature define a new counter type PORT_PHY_ATTR support added for polling following attributes, SAI_PORT_ATTR_RX_SIGNAL_DETECT, SAI_PORT_ATTR_FEC_ALIGNMENT_LOCK, SAI_PORT_ATTR_RX_SNR Add port_phy_attr_manager to set counter id list in FLEX_COUNTERS_DB Added unit tests to validate the enable/disable code flow, generatePortAttrCounterMap and QueryPortAttrCapabilitiesWithMockedSAI.
…s is Inband port (sonic-net#4157) What I did Fixed the bug reported in sonic-net/sonic-buildimage#25211 Fixed the bug introduced in sonic-net#4054 which was preventing the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port. Why I did it Fixed the bug introduced in sonic-net#4054 which prevents the ever flow mirror sessions becoming active in remote Asics. When the nexthop is added in remote asics in Voq systems, it is always added against the Inband port and not on the remote system port. So when the nexthop is resolved for the mirror session in the remote asic, the mirror code calls getNeighborEntry to find the nexthop entry by passing the nexthop of the route entry for the mirror destination. Since the nexthop was added on Inband port and getNeighborEntry was checking for RemoteSystemPort, finding nexthop was failing and hence the mirror session never gets activated in remote asics. So modified the code to include the isInbandPort check in addition to isRemoteSystemPortIntf . The isRemoteSystemPortIntf might be needed since the neighbor entries are added against the remote system port.
…cast. Signed-off-by: mint570 <runmingwu@google.com>
[P4Orch] Implement function to delete route entries that assign multicast.
Add .github/copilot-instructions.md for AI-assisted development
…ic-net#4578) * [zmqorch]: Restore drain-until-empty consumer for non-DPU/fabric PR sonic-net#3910 changed ZmqConsumer::execute() to perform a single batch pop per invocation, primarily to reduce peak memory in DASH (DPU) workloads. For non-DPU / non-fabric switches that receive high volumes of APPL_DB route updates from fpmsyncd, this regressed throughput: each execute() call no longer drains the consumer table, so updates take many more polls to apply. Introduce a ZmqRouteConsumer subclass that restores the prior drain-until-empty loop in execute(). ZmqOrch::addConsumer() selects ZmqRouteConsumer for non-DPU / non-fabric switch types; DPU and fabric continue to use ZmqConsumer to preserve the bounded-memory behavior added in sonic-net#3910. Also define gMySwitchType in orchagent/p4orch/tests/test_main.cpp so p4orch_tests links once zmqorch.cpp references the global. Signed-off-by: Venkit Kasiviswanathan <venkit@nexthop.ai>
…ges (sonic-net#4607) * stabilize PortsOrch mock tests after recent port config behavior changes What I did What this PR changes Makes autoneg set behavior in the test stub success-by-default, with explicit opt-in failure for failure-path tests. Keeps failure-injection coverage by explicitly toggling autoneg failure where intended. Improves cleanup/drain logic to avoid transient pending-task leftovers in bulk create/remove tests. Relaxes fragile set-call count assertions in PortAttributeSetOnCreation: allows base count or base+1 for FEC, TPID, and PFC (matching already-tolerant autoneg logic). Preserves semantic checks for final port state and attribute values. This PR fixes recent mock test failures in the PortsOrch unit-test suite by removing brittle assumptions about exact SAI set-call counts during port attribute handling. Why I did it What was failing The build target failed because mock tests in the PortsOrch suite failed and propagated a non-zero exit. Initial failures were in: PortBulkCreateRemove PortAttributeSetOnCreation After earlier fixes, one residual failure remained in PortAttributeSetOnCreation due to strict counter assertions.
* Fix gtest XML race in test wrapper Why I did it These test fixes were found while validating EVPN MH, but they are not EVPN-MH specific. Moving them to master separately improves shared test stability and reduces the EVPN MH PR scope. How I did it Made run-gtest-suite.py more robust for missing/delayed gtest XML output and FD pressure. Cleaned stale mgmt VRF state before in-band interface tests. Fixed mock test object lifetime leaks in fdborch/portsorch/routeorch tests. Stabilized mux prefix-route nexthop checks by polling for convergence and handling NHG members.
What I did Add the standalone EVPN multi-homing code and EVPN-MH focused tests as the first PR in the EVPN-MH stack. The code in this PR is refactored from PR:4262 This PR adds new EVPN-MH components and test sources without wiring the feature into existing production orchagent/cfgmgr/syncd behavior yet: New EVPN-MH orchestration components: orchagent/evpnmhorch.* orchagent/l2nhgorch.* orchagent/shlorch.* New FDB/neighbor helper header: fdbsyncd/neighbour.h New mock/test helper sources for EVPN-MH and VxLAN coverage: EVPN-MH orch mock tests FDB-in-VxLAN mock tests fdbsyncd EVPN-MH unit tests fpmsyncd EVPN-MH unit tests ShlOrch tests shared VxLAN unit-test helpers mock SAI FDB/tunnel helpers New SAG/EVPN pytest coverage source: tests/test_sag.py This PR is intentionally structured as the base of a stacked series. Follow-up PRs integrate these components into existing SONiC modules and then wire/update broader test infrastructure. Stack: This PR: standalone EVPN-MH code and EVPN-MH-focused tests. PR 2: integrate EVPN-MH with existing modules. PR 3: add/update broader tests and stabilization changes.
…sonic-net#4484) * [orchagent]: Use Redis pipeline for deferred DASH result table writes What I did Switched DASH result table writes in DashRouteOrch, DashVnetOrch, and DashTunnelOrch from immediate per-key Redis commands to batched writes using RedisPipeline. Each orch now constructs its result Table objects with buffered=true backed by a shared RedisPipeline instance, and calls a new flushResultsToDB() helper at the end of each doTask* method to flush all pending result writes in a single Redis round-trip. Why I did it Previously, each writeResultToDB() / removeResultFromDB() call issued an individual Redis round-trip to DPU_APPL_STATE_DB. For bulked DASH operations (routes, route rules, VNET mappings) that can process up to 1024 entries per doTask cycle via EntityBulker, this created N sequential Redis commands for result reporting — even though the SAI operations themselves were already batched. This change batches the result writes to match the existing SAI bulking pattern, reducing N Redis round-trips to 1 per doTask invocation.
…#4123) * Improve subnet randomization logic when NHG creation fails What I did Enhanced the temporary route creation logic when NHG (Next Hop Group) creation fails with multiple improvements: Better randomization with robust RNG Replaced rand() with std::mt19937 (Mersenne Twister) in both RouteOrch::addTempRoute() and NhgOrch::createTempNhg() Uses std::uniform_int_distribution for truly uniform nexthop selection Proper thread-local RNG initialization with std::random_device Sanity check for SAI limits Added warning when SAI returns suspiciously low MAX ECMP groups (< 128) Helps detect potential SAI bugs early Log elevation for better observability Elevated NHG exhaustion messages from DEBUG to NOTICE in: createFineGrainedNextHopGroup() addNextHopGroup() Includes actual limit value in warning messages Re-randomization guard for membership changes Track desired_nhg_key in RouteNhg struct Prevents unnecessary re-randomization when temporary route already points to a valid member Allows re-randomization when NHG membership changes (e.g., new nexthops come up) Reduces unnecessary dataplane churn
* countersyncd: make main actor supervision explicit What I changed replaced the current tokio::select! exit path with an explicit supervisor result classification in main.rs treat all spawned actors as critical: any actor exit now triggers daemon shutdown log which actor exited first and why abort the remaining actor tasks before terminating the process preserve the dedicated OpenTelemetry exit code when OTEL export retries are exhausted
* countersyncd: avoid blocking async actor loops What I changed moved SwssActor table polling onto a dedicated blocking reader thread replaced async-task std::thread::sleep(...) loops in control_netlink.rs with tokio::time::interval(...).tick().await reworked DataNetlinkActor's main loop to use async select! + interval-driven non-blocking recv instead of blocking sleep-based polling kept existing netlink/socket semantics intact (WouldBlock, ENOBUFS, reconnect flow)
* Download libyang3 in the build pipeline What I did When building in the PR check pipeline, download and install libyang3. Why I did it sonic-net/sonic-swss-common#973 changed swss-common to depend on libyang3
) * Skip swss.rec updates for high volume dash child objects What I did Added a per-consumer m_recordable flag to ConsumerBase and disabled swss.rec recording for high-volume DASH child object tables - DASH_ROUTE, DASH_ROUTE_RULE, DASH_VNET_MAPPING, DASH_ACL_RULE, DASH_PREFIX_TAG, DASH_METER_RULE, DASH_OUTBOUND_PORT_MAP_RANGE. Parent/configuration tables (ENI, APPLIANCE, VNET, ROUTE_GROUP, ACL_GROUP, METER_POLICY, HA_SET, etc.) continue recording normally. Why I did it When programming millions of DASH objects, writing every tuple to swss.rec is a performance bottleneck on the hot path. Each record involves dumpTuple string serialization, async queue enqueue, and eventual file I/O. For child objects at million-scale (route rules, VNET mappings, ACL rules, meter rules), this overhead is significant and the recording provides limited value since these are transient operational entries and also in protobuf format.
…ion safety (sonic-net#4566) Description Fixing infinite retry bugs and orchagent crashes caused by malformed DASH configs. Remove all retry logic from DASH orchestrators so that consumer notifications are always consumed. Add correct failure reporting to DPU_APPL_STATE_DB, partial failure cleanup for multi-SAI operations, and per-item exception handling to prevent malformed entries from getting stuck in the consumer. Changes 1. Remove retry logic (all DASH orchs) All DASH consumer loops now always erase entries from m_toSync, regardless of success or failure. Previously, entries were kept for retry when prerequisites were missing or SAI calls failed. task_need_retry returns changed to task_failed (ACL group mgr, tag mgr) it++ (retry) changed to it = consumer.m_toSync.erase(it) in all consumer loops SWSS_LOG_INFO("Retry as ...") upgraded to SWSS_LOG_ERROR(...) with descriptive messages naming both the missing parent object and the affected child entry return parseHandleSaiStatusFailure(...) replaced with explicit return true/false
What I did Fixed countersyncd IPFIX object-name resolution to use the current data set's template_id when selecting object_names, instead of picking an arbitrary key from the temporary/applied template maps. Added a regression unit test covering two template IDs with different object_names in the same input stream. Why I did it The previous logic could associate a data record with the wrong object_names set when multiple templates or sessions coexisted. That is a correctness issue: counters can be attributed to the wrong object instead of just being imprecise.
…ry (sonic-net#4315) * hftelorch: remove unused macro and add SAI return value checks What I did A collection of minor improvements and cleanups for the high frequency telemetry orchagent code: Add handleSaiCreateStatus() calls in createNetlinkChannel() for consistency with createTAM(). Add missing attrs.push_back() for SAI_TAM_REPORT_ATTR_REPORT_INTERVAL_UNIT. Use find() instead of operator[] in clearGroup() to avoid inserting default entries. Adjust clearGroup() cleanup order to delete counter subscriptions before telemetry type/report objects. Replace raw const char* fields in CounterNameMapUpdater::Message with owned std::string state for robustness. Initialize CounterNameMapUpdater::Message::m_oid to SAI_NULL_OBJECT_ID and keep it SET-only by contract. Use rvalue reference for updateStatsIDs() to enable true move semantics. Use u32 for SAI_TAM_COUNTER_SUBSCRIPTION_ATTR_STAT_ID to match the SAI metadata type. Clean up partially created hostif objects in createNetlinkChannel() if a later HOSTIF create step fails. Remove unused CONSTANTS_FILE macro and clean up commented-out code. Why I did it Identified during code review. Most of these are defensive robustness/maintainability fixes. The createNetlinkChannel() follow-up also improves failure-path behavior by avoiding leaked partially created HOSTIF objects when later create steps fail.
What I did Fixes a shared-MAC neighbor recovery bug in MuxOrch::updateFdb() introduced by sonic-net#4152. When two mux neighbors (e.g. standby ToR + SoC behind the same server) share a MAC, the function-scoped bool found_existing_mux_neighbor was set by any same-MAC hit in the loop over mux_nexthop_tb_. That gated off the fallback recovery block globally, so whenever the first loop re-bound one of the neighbors, the other — sitting as a plain NeighOrch entry after FDB age-out — stayed stranded and never got promoted back into mux_nexthop_tb_. Replace the boolean with std::set<NeighborEntry> handled that tracks the specific IPs the first loop already re-bound. The fallback now always runs when the FDB port is a mux, using handled as a skip filter to avoid re-processing. Why Reproduces like this on master: FDB primed → neighbor A added, gets MUX-managed FDB ages out (del_fdb) Neighbor B added while FDB is absent → stranded as plain NeighOrch entry FDB re-learned → updateFdb fires, loop (A) re-binds A, sets the flag, fallback skipped B stays stranded: no tunnel route, no ASIC neighbor entry
Wires every orchagent-owned `NotificationConsumer` to the swss-common primitives (companion PR) and adds `NotificationConsumerStatsOrch` to publish per-consumer counters to `COUNTERS_DB:NOTIFICATION_CONSUMER_STATS:<name>`.
**How I did it**
Consumer | Queue policy | Allowlist |
|---|---|---|
| `FdbOrch:fdb_event` | LruDedup | `{fdb_event}` |
| `FdbOrch:flush` | Fifo | `{ALL, PORT, VLAN, PORTVLAN}` |
| `PortsOrch:port_state_change` | LruDedup | `{port_state_change}` |
| `PortsOrch:port_host_tx_ready` (CMIS only) | LruDedup | `{port_host_tx_ready}` |
| `BfdOrch:bfd_session_state_change` | Fifo | `{bfd_session_state_change}` |
| `IcmpOrch:icmp_echo_session_state_change` | Fifo | `{icmp_echo_session_state_change}` |
| `TwampOrch:twamp_session_event` | Fifo | `{twamp_session_event}` |
| `P4Orch:port_state_change` | Fifo | `{port_state_change}` |
Each consumer also calls `setStatsLabel(...)` with the same key it registers under in `COUNTERS_DB:NOTIFICATION_CONSUMER_STATS:<name>`. The COUNTERS_DB publish includes:
| field | meaning |
|---|---|
| `channel` | Redis channel SUBSCRIBE'd to |
| `received` | total `processReply` admissions |
| `dropped_allowlist` | dropped at admission by the op-allowlist |
| `admitted` | `received - dropped_allowlist` |
| `admit_ratio_pct` | integer percent |
| `queue_policy` | `"Fifo"` or `"LruDedup"` |
| `lru_pushed` / `lru_dedup_hits` / `lru_dedup_ratio_pct` / `lru_current_depth` / `lru_high_watermark` | LruDedup consumers only |
`gNotifConsumerStatsOrch` is constructed early in `OrchDaemon::init` and added to `m_orchList`. All registration call sites null-check the global so unit-test contexts that don't construct an `OrchDaemon` remain unaffected.
Signed-off-by: Senthil Krishnamurthy <senthil@nexthop.ai>
…4624) What I did sonic-buildimage no longer builds the legacy libyang1 debs (libyang_1.0.73, libyang-cpp, python3-yang); it now builds only libyang3 (libyang3, python3-libyang). Updated the CI/build references in this repo that pull libyang from sonic-buildimage build assets to use the libyang3 debs via versionless globs: build-env/container-setup.py — libyang_*.deb → libyang3_*.deb, libyang-*_1.0*.deb → libyang-dev_*.deb dev/Dockerfile.yml — libyang_1.0.73_${PLATFORM}.deb → libyang3_*.deb README.md — manual install list → libyang3_* / libyang-dev_* The .azure-pipelines/* templates were already migrated to libyang3 upstream and needed no change. Why I did it Part of the libyang3 migration tracked in sonic-net/sonic-buildimage#22385. Once libyang1 is removed from sonic-buildimage, any step installing the old libyang_1.0.73 debs fails.
…net#4573) Signed-off-by: Rustiqly <rustiqly@users.noreply.github.com> Co-authored-by: Rustiqly <rustiqly@users.noreply.github.com>
What I did Implement the MAC Move Guard feature, a new component owned by FdbOrch that detects MACs flapping between ports faster than a configurable threshold and applies a configurable mitigation action. HLD: sonic-net/SONiC#2338 Two actions are supported: DISABLE_PORT — administratively disable all ports the flapping MAC was seen on except a "pinned" port, with reference counting so multiple bad MACs can require the same port disabled. DISABLE_LEARN_ON_MAC_WITH_ACL (DLOMWA) — install a pre-ingress ACL entry (vlan, smac) -> SAI_ACL_ACTION_TYPE_SET_DO_NOT_LEARN so the source MAC is not relearned while forwarding via the normal FDB lookup continues. Configuration is via the new CONFIG_DB MAC_MOVE_GUARD|GLOBAL row: enabled, threshold, detect_interval, action_interval, action. Per-platform capabilities are probed once at startup and published to STATE_DB MMG_CAPABILITY_TABLE|ACTIONS so consumers can discover which actions the platform supports before applying config. Recovery is timer-based on action_interval. STATE_DB persistence of admin-disabled ports lets the cleanup-on-restart sweep revert leftover hardware state on orchagent restart. HLD at: sonic-net/SONiC#2338 Why I did it MAC flapping (a single MAC bouncing between ports faster than the FDB can keep up) is a common symptom of Layer-2 loops, host misconfiguration, duplicate-MAC attacks, and certain VM-mobility bugs. Without a guard, the ASIC burns CPU on FDB churn, control-plane traffic suffers, and operators have no automated containment. MAC Move Guard provides a configurable detection threshold and two mitigation actions so the data plane can self-contain the offending MAC. Refer to the HLD for the full motivation and design rationale: sonic-net/SONiC#2338
* Write SAI failure state to state DB
What I did
Replaced the in-memory gOrchUnhealthy global boolean with a STATE_DB-backed health status table (PROCESS_HEALTH), enabling external reset of the orchagent unhealthy flag without restarting the process.
Changes:
Removed bool gOrchUnhealthy global variable from main.cpp, orchdaemon.cpp, saihelper.cpp, and mock_orchagent_main.cpp
Removed string gSaiErrorString global variable from main.cpp and mock_orchagent_main.cpp
Added PROCESS_HEALTH table in STATE_DB with key orchagent and fields unhealthy ("true"/"false") and error (failure description)
Added three non-static globals in saihelper.cpp: gHealthStateDb, gOrchHealthTable, gOrchUnhealthyCached
Added three functions in saihelper.h/saihelper.cpp:
initSaiFailureTable() — creates the STATE_DB connection and table object
setSaiFailureStatus() — writes health status to STATE_DB and updates a local cache
getSaiFailureStatus() — returns cached status; only reads STATE_DB when unhealthy (to detect external resets)
handleSaiFailure() calls setSaiFailureStatus(true, errorString) instead of setting global
OrchDaemon::start() loop calls getSaiFailureStatus() inside the existing SELECT_TIMEOUT periodic block, throttling the check to ~1/second
main() calls initSaiFailureTable() + setSaiFailureStatus(false) after option parsing, immediately before SAI initialization
Added 7 mock tests for initSaiFailureTable/setSaiFailureStatus/getSaiFailureStatus round-trip, including external reset detection and null table guard
Why I did it
The gOrchUnhealthy flag had no reset path — once set by a non-fatal SAI failure, it stayed true forever, causing the orchdaemon loop to log the error every ~1 second until the process was restarted. Moving the flag to STATE_DB allows operators to clear it externally:
sonic-db-cli STATE_DB HSET "PROCESS_HEALTH|orchagent" "unhealthy" "false"
sonic-db-cli STATE_DB HSET "PROCESS_HEALTH|orchagent" "error" ""
This also makes orchagent health status observable by other SONiC components via standard DB subscriptions.
…g teardown (sonic-net#4628) * Gracefully stop DVS services during teardown What I did When tearing down DVS tests, instead of using killall5 -15 to stop services in the DVS and generate the .gcda files needed to measure code coverage, use dvs.stop_swss() and supervisorctl stop all instead to ensure graceful shutdown of orchagent and other services. Why I did it VS tests rely on sending SIGTERM to processes in the DVS container to generate .gcda files containing code coverage information. sonic-net#4400 introduced graceful SIGTERM handling in orchagent which calls the OrchDaemon destructor which subsequently calls the destructors of each orch. Some of these destructors are dependent on other services (e.g. syncd). When the test session runs killall5 -15, it may kill other services (e.g. syncd) before the orch destructors finish running, causing orchagent to crash with SIGABRT and preventing the .gcda files from being generated. We can see that prior to the above PR being merged, overall code coverage was around 77% (https://dev.azure.com/mssonic/build/_build/results?buildId=1098386&view=codecoverage-tab). In the first successful pipeline run after the PR is merged, code coverage dropped to 55% (https://dev.azure.com/mssonic/build/_build/results?buildId=1100825&view=codecoverage-tab) which can be explained by the VS tests no longer providing coverage information for orchagent.
What I did Add minimal MUX subnet slicing to orchagent per HLD: sonic-net/SONiC#2318. A configured per-cable server_ipv6_subnet lets the cable disclaim per-host SAI neighbors for in-slice IPv6 addresses; traffic to those servers is forwarded via the slice prefix route (peer ToR tunnel) instead of a per-host neighbor entry. Suppression is gated on FDB port-affinity: an in-slice IPv6 is only suppressed when its MAC resolves to the slice cable's own port. In-slice IPs landing on any other port stay programmed and follow normal mux semantics. The anchor (server_ipv6) and skip neighbors (soc_ipv4/soc_ipv6) are never suppressed. server_ipv6_subnet is immutable once configured. This is a deliberately smaller scope than sonic-net#4611 — just the config + suppression gate + FDB move handling — to fit a 202605 inclusion window. Anchor supernet route, per-NH state machine, and route-ref un-/re-suppress are deferred. Why I did it Dualtor ToRs running with large in-slice neighbor counts were hitting neighbor / NHG table pressure. Suppressing the in-slice host neighbors that the slice prefix route already covers reclaims headroom without changing dataplane reachability for in-slice hosts.
* Download VPP artifact 'vpp-<debian version>' What I did In the pipeline definitions, parametrize the VPP artifact name. In azure-pipelines.yml set the artifact name based on the target Debian version. Why I did it VPP artifact names changed as a result of adding the Trixie build: sonic-net/sonic-platform-vpp#248
…c-net#4615) * Integrate EVPN-MH with existing modules Why I did it This is part 2/2 of splitting the original EVPN-MH PR (sonic-net#4262) into reviewable pieces. Part 1 (sonic-net#4608) landed the standalone EVPN-MH code (new orchs and headers added without touching existing files). This PR integrates EVPN-MH with the existing modules (NeighOrch, FdbOrch, VxlanOrch, RouteOrch, MuxOrch, p4orch, fpmsyncd, etc.) and adds the mock/VS tests that exercise both the standalone and integration paths. The test-infra prerequisites required to land these tests were merged separately as sonic-net#4599. How I did it Commit 1 — Integrate EVPN-MH with existing modules: wires the standalone EVPN-MH orchs (added in [EVPN-MH] Add standalone EVPN-MH code and tests sonic-net#4608) into the existing data plane (FDB / neighbor / next-hop / VXLAN / mux / p4orch / fpmsyncd). Commit 2 — Add EVPN-MH tests and stabilization updates: adds new mock_tests (neighorch, vxlanorch, p4orch fake/mock helpers) and VS tests (test_sag.py, EVPN FDB/L3 VXLAN updates) and a few small stabilization tweaks needed for the new tests. How to verify it make the swss debs and run mock_tests; test_sag.py and the new EVPN-MH cases under tests/mock_tests/{neighorch,vxlanorch}_ut.cpp should pass. Full VS suite locally and in CI.
Move route performance optimization knobs from DEVICE_METADATA|localhost to SYSTEM_DEFAULTS|route_performance table with two consolidated fields: - zmq: enables ZMQ for northbound (fpmsyncd->orchagent) and southbound (orchagent->syncd) communication - async_rec: enables async swss.rec recording and async APPL_STATE_DB route state publishing This replaces four separate knobs: - orch_northbond_route_zmq_enabled - orch_southbound_zmq_enabled - async_swss_rec - route_state_async_publish Add get_route_perf_zmq_enabled() and create_route_perf_zmq_client() helper functions that read from the new SYSTEM_DEFAULTS table. Signed-off-by: Deepak Singhal <deepsinghal@microsoft.com>
What I did
As per HLD, the decay-half-life should be less than max_suppress_time. Also, the reuse_threshold should be less than suppress_threshold. Added these two damping config params check and logged warning messages.
Why I did it
Added warning logs so that user knows the invalid configs are applied.
How I verified it
Unit test
Details if related
Decay half life more than max suppress time:
2026 Jun 8 10:51:31.563755 sonic NOTICE pmon#CmisManagerTask[39]: *** ('Ethernet24', 'CONFIG_DB', 'PORT') handle_port_update_event() fvp {'admin_status': 'up', 'alias': 'et-0/0/3', 'fec': 'rs', 'index': '3', 'lanes': '25,26,27,28,29,30,31,32', 'mtu': '9100', 'speed': '800000', 'dhcp_rate_limit': '300', 'link_event_damping_algorithm': 'aied', 'decay_half_life': '25000', 'flap_penalty': '1000', 'max_suppress_time': '20000', 'reuse_threshold': '1200', 'suppress_threshold': '1400', 'port_name': 'Ethernet24', 'asic_id': 0, 'op': 'SET'}
2026 Jun 8 10:51:31.566309 sonic WARNING swss#orchagent: :- setPortLinkEventDampingAiedConfig: Invalid link event damping configuration for port Ethernet24: decay_half_life (25000 ms) must not exceed max_suppress_time (20000 ms)
reuse_threshold greater than suppress_threshold:
2026 Jun 8 10:56:40.245543 sonic NOTICE pmon#CmisManagerTask[39]: *** ('Ethernet24', 'CONFIG_DB', 'PORT') handle_port_update_event() fvp {'admin_status': 'up', 'alias': 'et-0/0/3', 'fec': 'rs', 'index': '3', 'lanes': '25,26,27,28,29,30,31,32', 'mtu': '9100', 'speed': '800000', 'dhcp_rate_limit': '300', 'link_event_damping_algorithm': 'aied', 'decay_half_life': '15000', 'flap_penalty': '1000', 'max_suppress_time': '30000', 'reuse_threshold': '1600', 'suppress_threshold': '1500', 'port_name': 'Ethernet24', 'asic_id': 0, 'op': 'SET'}
2026 Jun 8 10:56:40.247985 sonic WARNING swss#orchagent: :- setPortLinkEventDampingAiedConfig: Invalid link event damping configuration for port Ethernet24: suppress_threshold (1500) must be greater than reuse_threshold (1600
…/fib (sonic-net#4394)" (sonic-net#4657) This reverts sonic-net#4394. What I did Remove build dependency on libnexthopgroup to unblock CI failures. This lib is not actively used in SWSS at the moment. Why I did it sonic-net/sonic-buildimage#27629 is part of the libyang1 to libyang3 migration and causes libnexthopgroup to not be built as part of the common-libs pipeline. Previously when the migration was in progress, both libyang1 and 3 were being built. All packages which were dependent on libyang3 (including libnexthopgroup transitively via FRR) were built as part of common-libs due to some serialization logic to prevent libyang1 and 3 from conflicting in sonic-buildimage at build time. Now that libyang1 is completely removed, this serialization logic doesn't exist anymore and libnexthopgroup is not built as part of common-libs, which causes the SWSS build to fail since libnexthopgroup is missing.
* Fix race condition between LAG and VLAN **What I did** - Fixed a LAG/VLAN race in `PortsOrch::doVlanMemberTask` (`orchagent/portsorch.cpp`): - Defer `VLAN_MEMBER` SET when the target port is a valid LAG member type (`isValidPortTypeForLagMember`: PHY or SYSTEM) and still has `m_lag_member_id` set in orchagent (symmetric to the existing guard that defers LAG member add while a VLAN member is pending — issue #23635). - Drop a pending `VLAN_MEMBER` DEL when the VLAN no longer exists in `m_portList` (avoids retrying a stale delete). - Added two mock regression tests under `VlanLagRaceTest` in `tests/mock_tests/portsorch_ut.cpp`: - `VlanMemberAddDeferredWhileLagMemberActive` — LAG member add completes first; VLAN member SET is deferred (asserts VLAN exists via `getPort`, port not in `vlan.m_members`, one pending SET). - `VlanMemberSucceedsAfterLagMemberRemoved` — after LAG member removal, the deferred VLAN member SET completes. **Why I did it** When a port is added to a LAG and a VLAN member SET is processed while orchagent still has `m_lag_member_id` set, `addBridgePort`/`addVlanMember` can call SAI too early. For some vendor this surfaces as `SAI_STATUS_INVALID_PORT_NUMBER` (rv:-9) and can leave a deferred SET retrying indefinitely. This is the inverse of #23635 (VLAN membership blocking LAG add); both come from table ordering and overlapping config during test teardown or fast config churn. **How I verified it** In the sonic-slave docker: ```bash cd /sonic/src/sonic-swss/tests/mock_tests make -j ./tests --gtest_filter=PortsOrchTest.LagMemberIsCreatedBeforeOtherObjectsAreCreatedOnLag:VlanLagRaceTest.* ``` All four tests pass, including the existing `LagMemberIsCreatedBeforeOtherObjectsAreCreatedOnLag` and `LagMemberAddDeferredWhileVlanMemberPending` cases. **Details if related** - The defer guard uses `isValidPortTypeForLagMember(port)` so only PHY/SYSTEM ports that can be LAG members are deferred. LAG interfaces (`PortChannel*`) are not LAG member types and remain addable as VLAN members even though they have `m_lag_id` set. - The DEL-on-missing-VLAN path handles cleanup when a VLAN is removed while a member task is still queued; a coalesced `VLAN_MEMBER` DEL from vlanmgr remains the normal production path. - `VlanMemberAddDeferredWhileLagMemberActive` uses a distinct port/LAG/VLAN (`PortChannel2` / `Vlan51`) from the success test because saivs state persists across tests in one gtest process. Signed-off-by: Stephen Sun <stephens@nvidia.com> * Potential fix for pull request finding Signed-off-by: Stephen Sun <stephens@nvidia.com> * Increase coverage Signed-off-by: Stephen Sun <stephens@nvidia.com> --------- Signed-off-by: Stephen Sun <stephens@nvidia.com>
Local ARS (Adaptive Routing and Switching) support. Co-authored-by: Vladimir Kuk <vkuk@marvell.com> Co-authored-by: Apoorv Sachan <apoorv@arista.com> Signed-off-by: apannerselva <apannerselva@marvell.com>
apannerselva
force-pushed
the
mrvl-local-ARS
branch
from
June 10, 2026 06:54
833056e to
38dc140
Compare
Signed-off-by: apannerselva <apannerselva@marvell.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Raised PR for internal comments