On Thu, 23 Mar 2017 10:08:00 -0700, Denny Page wrote:
I am very surprised at this. The application caching approach
requires the application retrieve the value via a system call. The
system call overhead is huge in comparison to everything else. More
importantly, the application cached value may be wrong. If the
application takes a sample every 5 seconds, there are 5 seconds of
timestamps that can be wildly wrong.
You can add a netlink event that is sent on speed change. No need for
polling then and the wrong timestamp window will be very tiny. (It
can't be zero, even with per-packet data.)
ethtool needs to be converted to netlink, anyway.
Jiri