[doc]: High frequency telemetry HLD#1795
Conversation
bc0e247 to
c14e643
Compare
There was a problem hiding this comment.
same here. these "guidance" words are better to be removed. very confusing to read.
There was a problem hiding this comment.
Sorry, Yes, there are many template "guidance" words I haven't removed them.
There was a problem hiding this comment.
i know the numbered prefix are not there in the template, but the doc will be much more readable with it. we should consider add them here.
There was a problem hiding this comment.
Hi @zhangyanzhao , Do you have any suggestions or concerns about adding a number prefix to each title in the template?
There was a problem hiding this comment.
Hi @zhangyanzhao , Do you have any suggestions or concerns about adding a number prefix to each title in the template?
Good suggestion. Updated the template. Github markdown does not support auto number yet, need community member to update it manually when creating HLD doc with the template.
There was a problem hiding this comment.
are we still uses the chunk size concept in our API?
There was a problem hiding this comment.
Or leverage the existing solution, time-based reporting?
Signed-off-by: Ze Gan <[email protected]>
Signed-off-by: Ze Gan <[email protected]>
290f7f9 to
0604b27
Compare
Signed-off-by: Ze Gan <[email protected]>
Signed-off-by: Ze Gan <[email protected]>
Signed-off-by: Ze Gan <[email protected]>
|
|
||
| - 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 enterprise bit is always set to 1 for stats records. | ||
| - The element ID of IPFIX is derived from the object index. For example, for `Ethernet5`, the element ID will be `0x5 | 0x8000 = 0x8005`. |
There was a problem hiding this comment.
Having a variable element ID per SAI object will blow up the number of templates in the report (separate template ID per port, queue etc.).
There was a problem hiding this comment.
In my mind, I assume all stats(per port, queue etc) in one profile will be encoded into ONE template. I will generate a unique template ID for a profile.
|
|
||
| ### Data format | ||
|
|
||
| We will use IPFIX as the report format, with all numbers in the IPFIX message in network-order (Big-endian). |
There was a problem hiding this comment.
You cannot make the assumption that data will be Big- or Little-endian. If it is collected by the ASIC and DMAd to a ring buffer, then kernel driver would need to correct the endianness of each data set. We need to have a bit in the element ID or Enterprise number that would indicate endianness.
There was a problem hiding this comment.
Are you worried that endian conversion will consume too many CPU clocks?
| ``` | ||
| STREAM_TELEMETRY_GROUP|{{profile_name}}|{{group_name}} | ||
| "object_names": {{list of object name}} | ||
| "object_counters": {{list of stats of object}} |
There was a problem hiding this comment.
How do you plan to handle the update of the counter list or object list from the report POV? is it going to be a new template ID?
There was a problem hiding this comment.
Yes, I assume we will use a new template ID.
We treat any configuration update as a new profile. The previous session will be interrupted. The SAI report object will get a new SAI_TAM_REPORT_ATTR_REPORT_IPFIX_TEMPLATE_ID
Signed-off-by: Ze Gan <[email protected]>
Signed-off-by: Ze Gan <[email protected]>
|
/azp run |
|
No pipelines are associated with this pull request. |
| key = HIGH_FREQUENCY_TELEMETRY_PROFILE|profile_name a string as the identifier of high frequency telemetry | ||
| ; field = value | ||
| stream_state = enabled/disabled ; Enabled/Disabled stream. | ||
| poll_interval = uint32 ; The interval to poll counter, unit microseconds. |
There was a problem hiding this comment.
hi Ze, should we add a remote write endpoint in this profile?
There was a problem hiding this comment.
What kind of endpoint? for OpenTelemetry collector or outside service like InflexDB?
There was a problem hiding this comment.
Done, please check it
Signed-off-by: Ze Gan <[email protected]>
|
/azp run |
|
No pipelines are associated with this pull request. |
|
|
||
| syncd ->> dma_engine: Config stats | ||
| syncd ->> hft_orch: Config was applied in the ASIC | ||
| syncd ->> hft_orch: Query IPFIX template |
There was a problem hiding this comment.
By this time DMA/Netlink module already know the IPFIX template to use for streaming of configured stats ? After syncd query the IPFIX template, what does it do with it? It's not clear from this flow or document on this. Please elaborate the flow sequence on how IPFIX template is programmed to DMA Engine/Netlink kernel modules?
There was a problem hiding this comment.
Hi @bendrapubalareddy , the dma engine and netlink module will both be provided by the vendor, we don't know when the IPFix template is programmed to the DMA Engine/Netlink kernel modules. So, we have a callback from SAI to notify the template is ready in SAI.
Here is its state machine, hope it can answer your question:
https://github.com/opencomputeproject/SAI/blob/master/doc/TAM/SAI-Proposal-TAM-stream-telemetry.md#tam-telemetry-type-state-machine
| ``` shell | ||
|
|
||
| # Add a new profile | ||
| sudo config high_frequency_telemetry profile add $profile_name --stream_state=$stream_state --poll_interval=$poll_interval --chunk_size=$chunk_size --chunk_count=$chunk_count |
There was a problem hiding this comment.
"otel_endpoint": {{string of endpoint}} (Optional)
"otel_certs": {{string of path}} (Optional)
should these optional attributes be added to high_frequency_telemetry profile config or they should be part of another config?
There was a problem hiding this comment.
Thanks for your point, we shuold support this new options in CLI.
| loop collect a chunk of stats | ||
| dma_engine ->> asic: query stats from asic | ||
| asic --) dma_engine: stats | ||
| dma_engine ->> netlink_module: Push stats |
There was a problem hiding this comment.
As per the "title: High frequency telemetry architecture" flow, dma_engine shall push the stats in IPFIX format to netlink module. If so, should we change "dma_engine ->> netlink_module: Push stats" to "dma_engine ->> netlink_module: Push stats in IPFIX format" ?
There was a problem hiding this comment.
Good suggestion. will fix it.
…rmat in stats push and adding new parameters for profile configuration
|
/azp run |
|
No pipelines are associated with this pull request. |
| 128-159: "Enterprise Number = 0x00010004" | ||
| 160-160: "1" | ||
| 161-175: "Element ID = 5 (port index)" | ||
| 176-191: "Field Length = 8 bytes" |
There was a problem hiding this comment.
Are the length is always expected to be 8 bytes only or different lengths other than 8 bytes are also accepted?
There was a problem hiding this comment.
It's always expected to be 8 bytes. Because we want to follow the design of SAI. The type of stats in SAI is uint64.
|
|
||
| ### 7.4. Config DB | ||
|
|
||
| Any configuration changes in the config DB will interrupt the existing session and initiate a new one. |
There was a problem hiding this comment.
What is meant by 'interrupt' here? We are assuming the existing session is deleted and a new session is created.
There was a problem hiding this comment.
From the perspective of a collector, a session is a set of groups with the same profile.
In the current SONiC implementation, we don't need to support changing the collector's session on the fly. But in the future, we would like to be able to add/remove or change the interval without interrupting any stats collection.
bandaru-viswanath
left a comment
There was a problem hiding this comment.
This document is generally light on SONIC-SAI workflow. Can you add some text describing the same ? Specifically -
- Are the counter capabilities retrieved and used ? What are the expectations ?
- If a counter reports as not supporting clear-on-read how does SONIC clear the counters ?
- How does SONIC handle the wrap-around conditions ?
- how does SONIC deal with the cases where HostCPU is too slow to empty the circular buffer ?
- If IPFIX template supplies a length (other than 8) for the counter, how is it handled ?
- How does SONIC use the SAI_TAM_TEL_TYPE_ATTR_MODE ?
- General overview of the design for SAI_SWITCH_ATTR_TAM_TEL_TYPE_CONFIG_CHANGE_NOTIFY ?
- How are the config and data threads kept synchronised ?
|
@Pterosaur If the counters are to be streamed from PIE port or front panel port of the ASIC directly, without sending to control plane sonic applications, that would be different config and this HLD does NOT want to have that option in it's config model. Is that understanding correct? |
@bendrapubalareddy We don't cover this scenario in this HLD, at least not in this version of HLD. |
Yes, we have query_stats_st_capability API in SAI, if the capability isn't supported, we will raise an error from syslog.
It's a typical problem of SONiC. According to the current SONiC solution, we will store the current snapshot of stats when we call clear action from SONiC side. And the UI will show the difference value of the stats.
Since we are using the 8bit(Uint64) for the counter, I believe that most of the time, it won't happen.
Drop the new stats. That's why we propose the ring buffer as the data structure.
It's always expected to be 8 bytes. Because we want to follow the design of SAI. The type of stats in SAI is uint64.
SONiC prefers SAI_TAM_TEL_TYPE_MODE_SINGLE_TYPE. We may use SAI_TAM_TEL_TYPE_MODE_MIXED_TYPE in the future for better efficiency. But due to the limitation of some vendors, we prefer SINGLE TYPE.
We have a state machine: https://github.com/opencomputeproject/SAI/blob/master/doc/TAM/SAI-Proposal-TAM-stream-telemetry.md#tam-telemetry-type-state-machine
In the phase 1, if we want to update the config, we have to delete the existing stream and create a new stream, this should be guarantee by SONiC side(orchagent) . And we leverage the tam telemetry type state machine to submit the config into the SAI level. |
|
Sync'ed with Bandaru offline and got his approval via email before the merge as well. |
High frequency telemetry HLD initial version
PRs:
sonic-net/sonic-swss-common#1006
sonic-net/sonic-sairedis#1573