[doc]: Clarify HFT enterprise number layout - #2346
Merged
Pterosaur merged 1 commit intoSep 5, 2026
Merged
Conversation
Signed-off-by: Ze Gan <ganze718@gmail.com>
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
🟡 Changes recommended
The updated bullet text conflicts with the adjacent EF bit diagram (which reserves the MSB of each 16-bit half for EF), so the description should be adjusted to avoid misleading readers when EF=1.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR clarifies the documentation for how the HFT IPFIX enterprise-number is encoded on the wire, correcting the example value to match the intended wire layout and decoder behavior.
Changes:
- Corrected the enterprise-number composition to place
SAI_OBJECT_TYPEin the high 16 bits and stats ID in the low 16 bits (network byte order). - Updated the worked example to
0x00150022and added the corresponding wire bytes00 15 00 22.
File summaries
| File | Description |
|---|---|
| doc/TAM/SAI-Proposal-TAM-stream-telemetry.md | Updates the enterprise-number encoding explanation and example for HFT IPFIX stream telemetry. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| - For high-frequency counters, the native IPFIX timestamp unit of seconds is insufficient. Therefore, we introduce an additional element, `observationTimeNanoseconds`, for each record to meet our requirements. | ||
| - The element ID of IPFIX is derived from the object index. For example, for `Ethernet5`, the element ID will be `0x5 | 0x8000 = 0x8005`, where `0x8000` indicates that the enterprise bit is set to 1. | ||
| - The enterprise number is derived from the combination of the [SAI_OBJECT_TYPE](https://github.com/opencomputeproject/SAI/blob/master/inc/saitypes.h) and its corresponding stats ID. The high bits are used to indicate the SAI extension flag. For example, for `SAI_QUEUE_STAT_WRED_ECN_MARKED_PACKETS=0x00000022` of `SAI_OBJECT_TYPE_QUEUE=0x00000015`, the enterprise number will be `0x00000022 << 16 | 0x00000015 = 0x00220015`. | ||
| - The first 16 bits of the enterprise number on the wire encode the [SAI_OBJECT_TYPE](https://github.com/opencomputeproject/SAI/blob/master/inc/saitypes.h), and the following 16 bits encode its stats ID. Multi-byte values use network byte order. Therefore, for `SAI_OBJECT_TYPE_QUEUE=0x00000015` and `SAI_QUEUE_STAT_WRED_ECN_MARKED_PACKETS=0x00000022`, the enterprise number is `0x00000015 << 16 | 0x00000022 = 0x00150022` (wire bytes `00 15 00 22`). |
Collaborator
Author
|
/azpw run |
Collaborator
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
DavidZagury
approved these changes
Sep 4, 2026
kcudnik
approved these changes
Sep 4, 2026
Pterosaur
added a commit
to sonic-net/SONiC
that referenced
this pull request
Sep 5, 2026
What I did Clarified the HFT IPFIX enterprise-number wire layout and corrected the example value: the first 16 bits on the wire encode the SAI object type; the following 16 bits encode the SAI stats ID; multi-byte values use network byte order. For queue type 0x0015 and stat ID 0x0022, this gives 0x00150022, or wire bytes 00 15 00 22. Why I did it The previous formula placed the stat ID in the high 16 bits and contradicted both the adjacent bit diagram and the current countersyncd HFT IPFIX decoder. How I verified it This is a one-line documentation correction. git diff --check passes and the old example value no longer appears in the HLD. The matching OCP SAI documentation change is submitted separately. Matching OCP SAI PR: opencomputeproject/SAI#2346 Signed-off-by: Ze Gan <ganze718@gmail.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
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.
What I did
Clarified the HFT IPFIX enterprise-number wire layout and corrected the example value:
For queue type
0x0015and stat ID0x0022, this gives0x00150022, or wire bytes00 15 00 22.Why I did it
The previous formula placed the stat ID in the high 16 bits and contradicted both the adjacent bit diagram and the current SONiC countersyncd HFT IPFIX decoder.
How I verified it
This is a one-line documentation correction.
git diff --checkpasses and the old example value no longer appears in the document.The matching sonic-net/SONiC HLD change is submitted separately.
Matching SONiC HLD PR: sonic-net/SONiC#2537