https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252850
Bug ID: 252850
Summary: Netmap doesn't update default packet statistics for
management entities
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Created attachment 221760
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221760&action=edit
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:
- IPACKET
- OPACKETS
- IBYTES
- OBYTES
etc.
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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
