bsnmpd follows RFC 2863 and provides 64-bit counters only when interface's ifi_baudrate is big enough.
Virtual interfaces like gif(4), gre(4), enc(4), lo(4), etc., usually have zero baudrate, and bsnmpd doesn't provide 64-bit counters for them.
This patch changes this - if in a system are present some HighSpeed interfaces, it is assumed, that virtual interfaces also capable to work at such speed.
Details
- Reviewers
harti trociny eugen_grosbein.net - Group Reviewers
network
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 16184 Build 16137: arc lint + arc unit
Event Timeline
Hmm I tried to add syrinx but she's not on Phab it seems.
Other question: why do we not set baudrate on the virtual interfaces?
I think first of it is historically, then it is because we don't know which value to set :)
Also there is related problem with LACP lagg: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193953
Maybe better solution is just provide 64-bit counters for all interfaces? It seems net-snmpd does so.
I did not do this in the past because it was not possible to add or increment 64-bit counters atomically. Did this change? Instead of providing bad values I decided to follow the words of the RFC.
I did not do this in the past because it was not possible to add or increment 64-bit counters atomically. Did this change? Instead of providing bad values I decided to follow the words of the RFC.
Today kernel achieves that. The getifaddrs API guarantees to report counter values to userland atomically.
How does it do that? The problem is whether a 64-bit increment or add is atomic with regard to a read from another CPU.
Ah, thanks. This looks fine. Then we really could go for 64-bit counters for all interfaces.