Skip to content

[Optimization] Improve traceroute_packetin_with_vrf_selection_test run time - #5806

Open
mansi0803 wants to merge 3 commits into
openconfig:mainfrom
mansi0803:refectorTraceRoutePacketInWithVrfSelectioTest
Open

[Optimization] Improve traceroute_packetin_with_vrf_selection_test run time#5806
mansi0803 wants to merge 3 commits into
openconfig:mainfrom
mansi0803:refectorTraceRoutePacketInWithVrfSelectioTest

Conversation

@mansi0803

@mansi0803 mansi0803 commented Jul 30, 2026

Copy link
Copy Markdown

traceroute_packetin_with_vrf_selection_test: Replace fixed sleep with telemetry watch to reduce test execution time

Refactor traffic waiting logic in to use on OTG telemetry counters instead of a fixed . This allows test cases to finish dynamically as soon as the target packet count (500 packets) is transmitted, significantly reducing total test execution time. In addition, cleaned up redundant , , and calls in and , ensuring OTG configuration and capture state are pushed once in after all flows are attached.

  • Replaced fixed sleep with on with an loop.
  • Cleaned up redundant OTG config push and protocol start calls.
  • Reducing the overall test duration by ~55%.

@mansi0803
mansi0803 requested a review from a team as a code owner July 30, 2026 09:33
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request optimizes the execution time of the traceroute_packetin_with_vrf_selection_test by transitioning from static wait times to event-driven telemetry monitoring. By leveraging gnmi.Watch on OTG counters, the test suite now concludes immediately upon reaching the required packet threshold, significantly reducing idle time. Additionally, the refactoring removes unnecessary configuration and protocol initialization steps, resulting in a cleaner and more efficient test setup.

Highlights

  • Performance Optimization: Replaced fixed sleep durations with dynamic telemetry watching using gnmi.Watch to monitor packet counters, allowing tests to complete as soon as the target packet count is reached.
  • Code Cleanup: Removed redundant OTG configuration pushes and protocol start calls to streamline the test execution flow.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@OpenConfigBot

OpenConfigBot commented Jul 30, 2026

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the traceroute packet-in tests to eliminate static sleeps by implementing real-time state detection via gnmi.Watch and .Await(t). It replaces duration-based traffic generation with a target packet count mechanism and removes redundant OTG configuration and protocol start steps. The review feedback recommends removing a redundant StartProtocols call in testTraffic to prevent protocol session flaps, and using t.Fatalf instead of t.Errorf when traffic fails to reach the target to fail fast.

Comment on lines +132 to +134
if !ok {
t.Errorf("Traffic flow %s did not reach the target of %d packets within the timeout", flow.Name(), targetPkts)
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

If the traffic flow fails to reach the target number of packets, the subsequent packet-in validations will inevitably fail or produce misleading results due to missing packets. Consider using t.Fatalf instead of t.Errorf to terminate the test immediately and avoid cascading failures.

Suggested change
if !ok {
t.Errorf("Traffic flow %s did not reach the target of %d packets within the timeout", flow.Name(), targetPkts)
}
if !ok {
t.Fatalf("Traffic flow %s did not reach the target of %d packets within the timeout", flow.Name(), targetPkts)
}
References
  1. In tests, t.Fatalf is preferred over t.Errorf when a failure makes subsequent test steps meaningless, as this fails fast and reduces overall test execution time.

@mansi0803 mansi0803 changed the title Optimize traceroute_packetin_with_vrf_selection_test run time [Optimization] traceroute_packetin_with_vrf_selection_test run time Jul 30, 2026
@mansi0803 mansi0803 changed the title [Optimization] traceroute_packetin_with_vrf_selection_test run time [Optimization] Improve traceroute_packetin_with_vrf_selection_test run time Jul 30, 2026
flow = append(flow, args.packetIO.GetTrafficFlow(args.ate, dstMac, isIPv4, 1, 300, 50, ipv4InnerDst, flowValue))
}
pktOut := testTraffic(t, args.top, args.ate, flow, srcEndPoint, 60, cs)
pktOut := testTraffic(t, args.top, args.ate, flow, srcEndPoint, 500, cs)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 500s? 60s seems fine.

… telemetry watch to reduce test execution time

Refactor traffic waiting logic in  to use  on OTG  telemetry counters instead of a fixed . This allows test cases to finish dynamically as soon as the target packet count (500 packets) is transmitted, significantly reducing total test execution time.
In addition, cleaned up redundant , , and  calls in  and , ensuring OTG configuration and capture state are pushed once in  after all flows are attached.
- Replaced fixed sleep with  on  with an  loop.
- Cleaned up redundant OTG config push and protocol start calls.
@mansi0803
mansi0803 force-pushed the refectorTraceRoutePacketInWithVrfSelectioTest branch from 77484a7 to 49eba6d Compare July 31, 2026 10:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants