fix(userspace): compute the drop ratio in the right way

[Andreagit97]

Signed-off-by: Andrea Terzolo andrea.terzolo@polito.it
Co-authored-by: Shane Lawrence shane@lawrence.dev

What type of PR is this?

/kind bug

/kind cleanup

Any specific area of the project related to this PR?

/area engine

What this PR does / why we need it:

First of all, I would to thank @shane-lawrence for spotting this issue in #2111! Great catch!

As I said here the n_evts fields, both in kmod and in bpf should be intended as "events seen by the drivers" so they should contain also the number of drops. This is for example what we do in our bpf probe after this variable increment we will increment also the drops number in case the event cannot be pushed into the buffer for example.

According to it, we need to change the way in which we compute the drop ratio

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

fix: compute the `drop ratio` in the right way

[FedeDP]

That's a great catch!
/approve

[poiana]

LGTM label has been added.

Git tree hash: 076ebb307859204d82cfe46e038f8554fc8a5e0e

[jasondellaluce]

/approve

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Andreagit97, FedeDP, jasondellaluce

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [FedeDP,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment