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
