Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VxLAN Tunnel Counters and Rates implementation #2

Closed
wants to merge 29 commits into from

Conversation

dgsudharsan
Copy link
Owner

Flexcounter implementation for vxlan tunnel counters and rates implementation

VenkatCisco and others added 12 commits July 7, 2021 11:41
…lobal context index. (sonic-net#832)" (sonic-net#859)

This reverts commit 0e2105a.
multi-asic VS with multiple swss and syncd dockers, comes up without context_config.json or hwinfo.
Just like a single asic vs, multi-asic vs will spawn multiple instances of swss and syncd with default hwinfo.
Reverting this PR as it is not required currently for multi-asic VS.
Will help using multiple switches in VS with multiple contextes.
…ilation instead of qemu emulation (sonic-net#852)

Current armhf Sonic build on amd64 host uses qemu emulation. Due to the nature of the emulation it takes a very long time, about 22-24 hours to complete the build. The change I did to improve the building time ports Sonic armhf build on amd64 host for Marvell platform for debian buster to use cross-compilation on arm64 host for armhf target. The overall Sonic armhf building time using cross-compilation is about 6 hours.

The Sonic configure and build for the armhf cross-compilation is as following:
NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 make configure PLATFORM=marvell-armhf PLATFORM_ARCH=armhf
NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 make target/sonic-marvell-armhf.bin

Sonic module should check if $CROSS_BUILD_ENVIRON is 'y' to make sure that it is cross-compilation build.

std::vector<uint64_t> tunnelStats(tunnelCounterIds.size());

// Get rif stats

Choose a reason for hiding this comment

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

I think here is a typo, should be tunnel but not rif

Copy link
Owner Author

Choose a reason for hiding this comment

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

Modified

}

uint64_t value;
for (int cntr_id = SAI_TUNNEL_STAT_IN_OCTETS; cntr_id <= SAI_TUNNEL_STAT_OUT_PACKETS; ++cntr_id)

Choose a reason for hiding this comment

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

Is it possible to pass counterIds vector to this update function and iterate through it here instead of using hardcoded values?
Otherwise, if values here are hardcoded, it could cause some issues in case number of tunnel counters change.

For example it is done like that in updateSupportedQueueCounters() function.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Updated

Use new api to record hardware info when creating switch for easy read. Since hardware info attribute type is s8list, it will be serialized as array of integers, so to actually improve readability of actual value, put it as comment in recording file.
When watchdog thread will exceed 30sec it will print currently executing event like create/remove/get/set. This data can be also found in sairedis.rec, but this PR will also print this in syslog for convenience.
@dgsudharsan dgsudharsan closed this Aug 7, 2021
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.

9 participants