[intfsorch]: Retry loopback action update failures - #4766
Conversation
|
/azp run |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
This PR improves IntfsOrch’s handling of loopback_action updates from APP_INTF_TABLE: it preserves SET tasks in the consumer queue when a retryable SAI failure occurs while updating the RIF loopback packet action, and it treats invalid loopback_action values as a logged no-op so other fields in the same SET can still be applied.
Changes:
- Validate
loopback_actionearly inIntfsOrch::doTask()and ignore invalid values (viagetSaiLoopbackAction()warning + skipping the field). - If setting the RIF loopback action fails in a retryable way, keep the
SETinm_toSyncso it will be retried on the next drain. - Add mock unit tests covering (1) retry behavior on SAI set failure and (2) ignoring invalid
loopback_actionwhile still applying other fields (e.g., MTU).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
orchagent/intfsorch.cpp |
Adds loopback_action validation and retry behavior so requested loopback action updates aren’t lost on retryable SAI errors. |
tests/mock_tests/intfsorch_ut.cpp |
Adds unit tests to verify retry-on-failure and ignore-invalid-field behavior for loopback_action. |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
/azpw run |
|
Retrying failed(or canceled) jobs... |
|
Retrying failed(or canceled) stages in build 1169337: ✅Stage TestAsan:
✅Stage Test:
|
|
/azp run |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
Hi — this PR has a cherry-pick conflict for the 202605 branch ( If you need help identifying the conflicting changes, let us know. Thanks! Comment by @vaibhavhd via automated tooling |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
The Tested branch section has been ticked and Test result is provided for branch(es): 202605. Added label(s): Tested for 202605 Branch. ---Powered by SONiC BuildBot
|
Keep false reserved for retryable SAI failures so the caller can retain only tasks that may converge on a later drain. Invalid loopback-action values remain terminal and do not block unrelated fields in the same interface update. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
tests/mock_tests/intfsorch_ut.cpp:24
- The UT stubs for
create_router_interface/remove_router_interfacereturnSAI_STATUS_SUCCESSwithout setting*router_interface_idor calling the original SAI implementation. With the newly addedset_router_interface_attributehook forwarding topold_sai_rif_api,port.m_rif_idcan remainSAI_NULL_OBJECT_IDand the test may exercise SET behavior against an invalid RIF ID (passing/failing for the wrong reason). Forward create/remove to the original API (or at least initialize*router_interface_id) so loopback-action SETs operate on a valid object.
bool fail_next_rif_set = false;
sai_packet_action_t last_loopback_action = SAI_PACKET_ACTION_FORWARD;
sai_router_interface_api_t *pold_sai_rif_api;
sai_router_interface_api_t ut_sai_rif_api;
Return success directly for the loopback-action attribute handled by the unit-test hook. Continue delegating every unrelated RIF attribute to the original SAI implementation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (2)
tests/mock_tests/intfsorch_ut.cpp:540
- After the first drain, this test asserts
saw_loopback_actionis false, but that currently just means the mock didn’t record the attempted SET (it only flips on success). Once the mock records attempts, update the assertions to ensure the loopback-action SET was attempted on the first drain (failed + retained) and then attempted again on the second drain (succeeded).
ASSERT_EQ(consumer->m_toSync.size(), 1u);
ASSERT_FALSE(saw_loopback_action);
static_cast<Orch *>(gIntfsOrch)->doTask();
tests/mock_tests/intfsorch_ut.cpp:56
- In the SAI set-attribute mock,
saw_loopback_actionis only set on success. When the first call returnsSAI_STATUS_INSUFFICIENT_RESOURCES, the test can’t distinguish “setter wasn’t called” from “setter was called and failed”. Record the attempted action (and mark it as seen) before injecting the failure so the test can assert the retry path was actually exercised.
This issue also appears on line 536 of the same file.
if (fail_next_rif_set)
{
fail_next_rif_set = false;
return SAI_STATUS_INSUFFICIENT_RESOURCES;
}
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Suppressed comments (1)
tests/mock_tests/intfsorch_ut.cpp:42
_ut_set_router_interface_attribute()delegates non-loopback attributes to the original SAI RIF API, but_ut_create_router_interface()/_ut_remove_router_interface()currently just return success without calling through. That means delegated SETs can be executed on a non-existent RIF object (invalid OID), making the hook fragile if any test path triggers other RIF attribute updates.
To keep the “intercept only loopback_action, delegate everything else” model consistent, consider calling through to the original create/remove while still maintaining the counters.
++remove_rif_count;
return SAI_STATUS_SUCCESS;
}
sai_status_t _ut_set_router_interface_attribute(
Delegate router-interface creation, removal, and unrelated attribute updates to the original SAI implementation. Count loopback-action SET attempts before failure injection so the retry test proves both attempts occurred. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b6b568a1-5d2a-4309-b1ac-ef21ca155079 Signed-off-by: Xichen96 <lukelin0907@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
What I did
Fixed dynamic
loopback_actionupdates on an existing router interface so retryable SAI failures retain the APP_DB task instead of silently losing the requested action.Historically,
loopback_actionwas normally supplied while creating a RIF.setIntf()passed it toaddRouterIntfs(), which includedSAI_ROUTER_INTERFACE_ATTR_LOOPBACK_PACKET_ACTIONin the CREATE attributes.The operation exposing this bug changes an existing RIF dynamically between
DROPandFORWARDwithout recreating it. That path callssetIntfLoopbackAction()fromIntfsOrch::doTask().Before:
After:
The helper follows the existing
IntfsOrchboolean-setter convention:falsemeans retry is required;truemeans processing is terminal and should not be retried. Therefore an invalid action logs a warning and returnstruewithout issuing a SAI call, allowing unrelated fields in the same row to converge.The change remains surgical:
setIntf()still owns the RIF lifecycle, andsetIntfLoopbackAction()remains the single-attribute SAI setter.Why I did it
A transient SAI resource condition must not silently discard desired state. Dynamic loopback packet-action updates need the same retain-and-retry behavior used by other retryable SAI operations.
Invalid input is different: it cannot converge on a later drain and must not leave the whole row queued forever. For example:
The invalid action is ignored, while
nat_zone=7is still applied and the task is consumed.This issue is independent of the interface-removal and VRF-rehome state machines in PRs #4746 and #4764.
How I verified it
Focused mock coverage verifies:
IntfsOrchRetriesLoopbackActionSetFailureSAI_STATUS_INSUFFICIENT_RESOURCESresult for the loopback-action attribute;m_toSync;SAI_PACKET_ACTION_DROPis applied.IntfsOrchIgnoresInvalidLoopbackActionFieldnat_zone=7;Current head:
d1ef1b15481ae09passed all architecture, ASAN, Docker, Trixie, regular vstest, and ASAN vstest lanes in build 1179543:https://dev.azure.com/mssonic/be1b070f-be15-4154-aade-b1d3bfb17054/_build/results?buildId=1179543
Details if related
202605.Cherry Pick Conflict_202605label.Tested for 202605 branch:https://msazure.visualstudio.com/One/_workitems/edit/38514061
IntfsOrchpaths.