Page MenuHomeFreeBSD

In snmp_mibII module assume that virtual interfaces can work at maximum speed available in the system
AcceptedPublic

Authored by ae on Apr 17 2018, 1:10 PM.

Details

Reviewers
harti
trociny
eugen_grosbein.net
Group Reviewers
network
Summary

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.

Diff Detail

Repository
rS FreeBSD src repository
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 16184
Build 16137: arc lint + arc unit

Event Timeline

ae created this revision.Apr 17 2018, 1:10 PM
bz added a subscriber: bz.Apr 17 2018, 1:20 PM

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?

ae added a comment.Apr 17 2018, 1:39 PM
In D15112#318277, @bz wrote:

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

ae added a comment.Apr 17 2018, 1:40 PM

Maybe better solution is just provide 64-bit counters for all interfaces? It seems net-snmpd does so.

This revision is now accepted and ready to land.Apr 17 2018, 1:53 PM
harti added a comment.Apr 17 2018, 2:26 PM
In D15112#318283, @ae wrote:

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.

harti added a comment.May 7 2018, 12:00 PM

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.

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.

This is described in counter(9) manual page.

harti added a comment.May 8 2018, 6:25 AM

Ah, thanks. This looks fine. Then we really could go for 64-bit counters for all interfaces.