* Add Gigawords to radius packets where applicable.
IMPORTANT NOTE: The ioctl() only supports 32-bit counters. In order t
obtain 64-bit counters, these are now pulled in from sysfs (it's assumed
to be mounted on /sys which I'm assuming is standard).
It is unknown whether sysfs will be available everywhere, as such, keep
the ioctl() method in place, but attempt to detect wrap-overs.
If the sysfs mechanism fails, fail back to the ioctl().
Given maximum data rates, the intervals between calling this needs to be
such that no more than 4GB (2^32) bytes are sent or received in any
given interval. Mostly important for radius plugin where data
accounting may be in effect.
Towards this, a timer interval on 25 seconds is set to force a ioctl()
poll irrespective of the rate of stats update calls. This may be
important for especially radius that needs to provide interim-update
intervals, if the interim updates is too long and the counters could
wrap-over twice in a single interval. At 25 seconds we should detect
all wraps up to an effective data rate of 1.37Gbps, which for my
purposes is adequate.
Possible downsides, 4 files are opened, read and closed every time
statistics is requested. This results in 12 system calls every single
time statistics is required, compared to 1 for the ioctl. Efficiency is
unknown, but as a rule of thumb fewer system calls are better, this is
however not a critical path in my opinion, so should not be a problem.
If required I can run a few benchmarks using gettimeofday() to measure
actual impact.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
* Use netlink if possible to obtain 64-bit stats.
This uses two system calls per round.
This should be preferred where available. It seems the RTM_GETSTATS was
only added from 2016 some point (4.7.0 as per pali), which is in my
opinion old, but given experience with certain embedded systems does
need to be supported.