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

dpdk: replace TSC clock with GetTime (gettimeofday) function v1 #11389

Closed
wants to merge 1 commit into from

Conversation

lukashino
Copy link
Contributor

Getting time through the Time Stamp Counter (TSC) can be precise and fast, however only for a short duration of time.
The implementation across CPUs seems to vary. The original idea is to increment the counter with every tick. Then dividing the delta of CPU ticks by the CPU frequency can return the time that passed. However, the CPU clock/frequency can change over time, resulting in uneven incrementation of TSC. On some CPUs, this is handled by extra logic. As a result, obtaining time through this method might drift from real-time.

This commit therefore substitutes TSC time retrieval by the standard system call wrapped in the GetTime function - on Linux it is gettimeofday.

Ticket: 7115
https://redmine.openinfosecfoundation.org/issues/7115

Describe changes:
v1

  • initial work

Getting clock through Time Stamp Counter (TSC) can be precise and fast,
however only for a short duration of time.
The implementation across CPUs seems to vary. The original idea is to
increment the counter with every tick. Then dividing the delta of CPU ticks
by the CPU frequency can return the time that passed.
However, the CPU clock/frequency can change over time, resulting in uneven
incrementation of TSC. On some CPUs this is handled by extra logic.
As a result, obtaining time through this method might drift from the real
time.

This commit therefore substitues TSC time retrieval by the standard system
call wrapped in GetTime function - on Linux it is gettimeofday.

Ticket: 7115
@victorjulien
Copy link
Member

Is there a performance impact?

@lukashino
Copy link
Contributor Author

I was playing around with it and no (major) performance impact was observed.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 21332

@lukashino
Copy link
Contributor Author

rebased version in #11409

@lukashino lukashino closed this Jul 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants