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/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252850 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=3D221760&action= =3Dedit 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 sys= ctl 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=20 - OPACKETS - IBYTES - OBYTES etc. If a driver does NOT collect these statistics, such as Intel, the system re= lies on a default counter which gets incremented as soon as a packet makes its w= ay 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 applicat= ions control whether packets are passed up the host stack. 2. Increase the default counters right before netmap_{rx/tx}sync has finish= ed executing. This has the effect that ALL packets and bytes which enter the system are recorded, causing the numbers to be representative of the underl= ying hardware, as is intended through iflib's ifdi_get_counter() function. Please find attached a proposed patch for this. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252850-227>