Bug 252850 - Netmap doesn't update default packet statistics for management entities
Summary: Netmap doesn't update default packet statistics for management entities
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2021-01-20 08:16 UTC by Stephan de Wit
Modified: 2021-08-18 07:21 UTC (History)
2 users (show)

See Also:

patch for the above-described bug (2.49 KB, patch)
2021-01-20 08:16 UTC, Stephan de Wit
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan de Wit 2021-01-20 08:16:34 UTC
Created attachment 221760 [details]
patch for the above-described bug

Certain userspace applications might want to keep track of RX/TX bytes and packets, which are fed into the if_mib structure and accessible via the sysctl net.link.generic.ifdata.[IF_INDEX].{general/linkspecific}. The handler for this calls if_data_copy(), which in turn calls a driver-specific function which checks if certain statistics are available in the hardware, such as:

If a driver does NOT collect these statistics, such as Intel, the system relies on a default counter which gets incremented as soon as a packet makes its way through the datapath in iflib.

However, when the interface is in NETMAP mode, these counters are not incremented. This means that any management entities keeping track of bytes and packets do not see anything coming through.

The fix for this (unless this was intentionally left out?) has two options in my opinion:
1. Increase default counters as the system would, right after if_input() is called. This undermines the idea of Netmap though, since userspace applications control whether packets are passed up the host stack.
2. Increase the default counters right before netmap_{rx/tx}sync has finished executing. This has the effect that ALL packets and bytes which enter the system are recorded, causing the numbers to be representative of the underlying hardware, as is intended through iflib's ifdi_get_counter() function.

Please find attached a proposed patch for this.
Comment 1 Kevin Bowling freebsd_committer 2021-08-18 07:21:29 UTC
Committed in 66fa12d8fb61485780f32f0226e79d3389567496