Date: Wed, 20 Jan 2021 08:16:34 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 252850] Netmap doesn't update default packet statistics for management entities Message-ID: <bug-252850-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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: bugs@FreeBSD.org Reporter: stephan.dewt@yahoo.co.uk 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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252850-227>