fix(perf): TRex ASTFIPGen.glob type + client ip_gen (profile build)#106
Merged
Conversation
…_gen Run 28540393082 (post-#105) cleared the ip_range error and hit the next profile-build ArgVerify: ASTFIPGen 'glob' must be ASTFIPGenGlobal, not ASTFIPGenDist. Reviewed the whole build_tcp_profile against the TRex ASTF API and fixed two issues at once to avoid another EC2 round-trip: - glob=ASTFIPGenGlobal(ip_offset='1.0.0.0') (was ASTFIPGenDist) - ASTFTCPClientTemplate now passes ip_gen= (canonical form) Regression check asserts glob is not an ASTFIPGenDist. NOTE: this is the 4th TRex-profile API error found one-at-a-time on real hardware — the ASTF profile was never validated against TRex. Follow-up: validate build_tcp_profile offline (TRex control-plane ArgVerify is pure Python) so these are caught in <1s instead of a 30-min EC2 run. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Synthetic Performance Results — Graviton (run)Commit: ✅ synthetic UDP socket bound to 10.0.0.1:9000 (MAC: 02:00:00:00:00:01) Synthetic UDP Performance ResultsMeasures framework overhead: sync IPv4 Baseline
IPv6
IPv6 vs IPv4 Comparison (sync path)
IPv4 avg sync/async ratio: 0.9x, worst: 1.0x | IPv6 vs IPv4 worst ratio: 1.29x (OK)
|
Synthetic Performance Results (run)Commit: ✅ synthetic UDP socket bound to 10.0.0.1:9000 (MAC: 02:00:00:00:00:01) Synthetic UDP Performance ResultsMeasures framework overhead: sync IPv4 Baseline
IPv6
IPv6 vs IPv4 Comparison (sync path)
IPv4 avg sync/async ratio: 0.9x, worst: 1.0x | IPv6 vs IPv4 worst ratio: 1.24x (OK)
|
[CI] Stage: DeployInfrastructure ready.
|
[CI] Stage: DeployInfrastructure ready.
|
[CI] Stage: SummaryAll tests PASSED. ARP seeding: kernel /proc/net/arp (automatic)
|
✅ Integration Tests Passed — Graviton (run)Branch: Test Results
Application Logs (last 20 lines)receiver-echo-server.log sender-echo-server.log sender-test-client.log |
[CI] Stage: SummaryAll tests PASSED. ARP seeding: kernel /proc/net/arp (automatic)
|
✅ Integration Tests Passed (Run 28542011384)Branch: Test Results
Application Logs (last 20 lines)receiver-echo-server.log sender-echo-server.log sender-test-client.log receiver-test-client-iperf.log sender-test-client-iperf.log Full Application Logs (last 200 lines each)receiver-echo-server.logsender-echo-server.logsender-test-client.logreceiver-test-client-iperf.logsender-test-client-iperf.log
|
gspivey
added a commit
that referenced
this pull request
Jul 1, 2026
…107) Follow-up to #106. Run [28549496895](https://github.com/gspivey/dpdk-stdlib-rust/actions/runs/28549496895) hit `unexpected keyword argument 'port'`. **This is the 5th TRex-profile API error found one-at-a-time on EC2 — so instead of guessing again, I built the offline validator we discussed.** ### The fix (ground-truthed, not guessed) Stood up the TRex control-plane profile module locally (its `ArgVerify` is pure Python — no NIC/server) and introspected the real API: - `ASTFAssociation(rules=...)` — does **not** take `port=`; the port goes on `ASTFAssociationRule(port=...)`. - `ASTFTCPClientTemplate` **does** accept `port=` (my #106 change there was fine). Fixed the association, and **confirmed `build_tcp_profile()` builds a valid `ASTFProfile` for all payload sizes offline in <1s.** ### The tool (ends the whack-a-mole) `scripts/perf-tests/test/validate_tcp_profile.sh` — sparse-clones the TRex control-plane, shims `cgi` (py3.13) + `zmq` (arm64), and builds the profile locally. Any future ASTF-API mistake is caught in <1s instead of a ~30-min EC2 run. Directly addresses the "testing at deployment is expensive" concern. Follow-up: wire it into CI as a per-PR gate. Merge → the next EC2 run should finally get **past profile-build** to real CPS/throughput (or a genuine *runtime* issue, no longer a profile-build error). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.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
1 participant
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.
Follow-up to #105 (which cleared the
ip_rangeerror). Run 28540393082 hit the nextArgVerify:Reviewed the whole
build_tcp_profileagainst the TRex ASTF API and fixed two things at once:glob=ASTFIPGenGlobal(ip_offset="1.0.0.0")(was anASTFIPGenDist— wrong type).ASTFTCPClientTemplatenow passesip_gen=(canonical form).py_compileclean, harness tests green, + a regression check for the glob type.This is the 4th TRex-profile API error found one-at-a-time via ~30-min EC2 runs — that ASTF profile was clearly never validated against a real TRex, and one-per-run is exactly the expensive-testing trap. Strongly recommend a follow-up: validate
build_tcp_profileoffline (the TRex control-planeArgVerifyis pure Python — no NIC needed) so all such errors surface in <1s locally. I can set that up instead of continuing the EC2 whack-a-mole — your call.🤖 Generated with Claude Code