[doc] High frequency telemetry support of MIXED tam tel type mode HLD#2379
Open
DavidZagury wants to merge 7 commits into
Open
[doc] High frequency telemetry support of MIXED tam tel type mode HLD#2379DavidZagury wants to merge 7 commits into
DavidZagury wants to merge 7 commits into
Conversation
Collaborator
|
/azp run |
Signed-off-by: david.zagury <davidza@nvidia.com>
What I did Add a new §7.6.1 "CounterSyncd label resolution in MIXED" that describes the aggregating per-record lookup CounterSyncd performs across the per-group sessions that share a template_id in MIXED. Tighten the surrounding "no CounterSyncd changes" claims in §2, §5, §6, and §7.6 so they distinguish the unchanged public interface (STATE_DB schema, IPFIX wire format, OpenTelemetry export) from the contained internal extension. Add a sentence to the §12 m_next_label limitation bullet making explicit that the monotonic per-profile allocation is the design contract that the §7.6.1 aggregation relies on. Update the table of contents to include §7.6.1. Why I did it The original HLD claimed "no CounterSyncd changes" in three places on the assumption that per-profile-unique labels alone would let the existing single-session lookup resolve every field. In practice CounterSyncd routes data records to sessions by template_id, and in MIXED multiple per-group sessions share a template_id, so the single-session lookup picks one session by last-writer-wins and labels owned by sibling sessions fall back to unknown_<N>. The implementation adds session_template_ids and an aggregating lookup that unions every contributing session's object_id_name_map; the HLD now documents this and is consistent with the shipped behavior. The Enterprise=0 padding-field defensive filter in CounterSyncd remains out of scope here - it is vendor-quirk handling and not part of the MIXED design. Signed-off-by: david.zagury <davidza@nvidia.com>
DavidZagury
force-pushed
the
master_hft_mixed_mode
branch
from
June 10, 2026 15:40
a673312 to
00a7d61
Compare
Collaborator
|
/azp run |
|
No pipelines are associated with this pull request. |
Pterosaur
reviewed
Jun 16, 2026
| | `MIXED_TYPE` only | MIXED_TYPE | yes | | ||
| | neither | - | no (logged) | | ||
|
|
||
| SINGLE_TYPE is preferred when both are advertised so that the behavior of all existing platforms is unchanged. This is consistent with the SAI specification, which declares `SAI_TAM_TEL_TYPE_MODE_SINGLE_TYPE` as the default value of `SAI_TAM_TEL_TYPE_ATTR_MODE`. |
Contributor
There was a problem hiding this comment.
IMHO, MIXED_TYPE can be the default behavior in the Orchagent, since mixed_type mode is more efficient and uses fewer states and SAI objects.
Author
There was a problem hiding this comment.
I have no objection to using MIXED_TYPE as default. I was just not sure there will be no issues with other vendors with changing that behavior. If you think there shouldn't be an issue with changing the behavior I will agree.
Contributor
There was a problem hiding this comment.
I think it's not an issue. I can discuss it with other vendors.
Contributor
There was a problem hiding this comment.
Could you please update the default mode to mixed_type in this document?
Contributor
There was a problem hiding this comment.
I would also vote for mixed_type, because it is much better. If mixed_type is not supported, we can always fallback to single type anyway.
Signed-off-by: david.zagury <davidza@nvidia.com>
Signed-off-by: david.zagury <davidza@nvidia.com>
Signed-off-by: david.zagury <davidza@nvidia.com>
Signed-off-by: david.zagury <davidza@nvidia.com>
Contributor
|
Hi @DavidZagury , It looks like the local commit hasn’t been pushed yet. |
Collaborator
|
/azp run |
|
No pipelines are associated with this pull request. |
Author
@Pterosaur pushed |
Pterosaur
reviewed
Jun 19, 2026
Collaborator
|
/azp run |
|
No pipelines are associated with this pull request. |
…de-hld.md Co-authored-by: Ze Gan <ganze718@gmail.com> Signed-off-by: david.zagury <davidza@nvidia.com>
DavidZagury
force-pushed
the
master_hft_mixed_mode
branch
from
June 30, 2026 12:47
6d7edd7 to
2aa7816
Compare
Collaborator
|
/azp run |
|
No pipelines are associated with this pull request. |
5 tasks
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
4 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.
Summary
Extends the existing High frequency telemetry HLD (https://github.com/sonic-net/SONiC/blob/master/doc/high-frequency-telemetry/high-frequency-telemetry-hld.md) to add support for SAI_TAM_TEL_TYPE_MODE_MIXED_TYPE. Some vendor SAI implementations advertise only MIXED_TYPE, on which SONiC HFT cannot be enabled today because the orchagent hardcodes SAI_TAM_TEL_TYPE_MODE_SINGLE_TYPE.
The change is additive and orchagent-internal:
No changes to CONFIG_DB, YANG, CLI, STATE_DB schema, IPFIX wire format, or the OpenTelemetry exporter. The mode is selected once at orchagent init and fixed for its lifetime — no runtime mode switching in this phase.
Related implementation PR