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

Various statistics counters for NFV apps #953

Merged
merged 44 commits into from
Jul 13, 2016

Conversation

eugeneia
Copy link
Member

@eugeneia eugeneia commented Jun 24, 2016

Depends on: #931 #949

This adds statistics/diagnostics counters for various NFV apps.

  • L2TPv3 app counts rxerrors broken down into why
  • ESP tunnel counts rxerrors (not insanely useful, can most of the time be inferred from link statistics)
  • nd_light has status (initially link down, link up once neighbor established), rxerrors (erroneous packets from south dropped, boken down into why), txerrors (erroneous packets from north), and txdrop (packets from north dropped while link down)
  • pcap_filter counts rxerrors and sessions_established
  • rate_limiter counts txdrop (again, not insanely useful)

If the recurring boilerplate code wasn't obvious until now, this PR shows it pretty prominently. My next step will be to abstract away the boilerplate I added in my recent PRs... :-)

lukego and others added 30 commits February 22, 2016 13:35
Set the shared memory path (shm.path) to a private namespace for each
app with prefix "app/$name".

This means that apps can create shm objects such as counters and by
default these will appear in a local namespace for that app.
 - Use "apps/" instead of "app/" for uniformity
 - Set shm path to "apps/$name" when calling `app:stop' too
 - Unlink "apps/$name" after `app:stop' using `shm.unlink'
 - Add a test case to core.app selftest
option and support injecting a function to determine the
current time.
# Conflicts:
#	src/core/counter.lua
@kbara kbara self-assigned this Jul 1, 2016
@kbara
Copy link
Contributor

kbara commented Jul 4, 2016

Both dependencies have been merged into next, but not via the same upstream branch. Any thoughts on the most reasonable way to proceed on this patch set short of waiting for an extra release, @lukego ?

@eugeneia
Copy link
Member Author

eugeneia commented Jul 5, 2016

@kbara You could merge next into kbara-next, then merge this PR.

@kbara
Copy link
Contributor

kbara commented Jul 5, 2016

Good idea; I've done so.

@eugeneia eugeneia merged commit d52d89c into snabbco:master Jul 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants