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.
Tags
None
Referenced Files
Unknown Object (File)
Dec 23 2023, 2:13 PM
Unknown Object (File)
Dec 20 2023, 8:07 AM
Unknown Object (File)
Oct 31 2023, 10:40 AM
Unknown Object (File)
Oct 19 2023, 12:14 PM
Unknown Object (File)
Sep 29 2023, 10:39 AM
Unknown Object (File)
Sep 12 2023, 1:18 AM
Unknown Object (File)
Sep 1 2023, 9:23 PM
Unknown Object (File)
Jun 24 2023, 4:28 AM
Subscribers

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 - 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?

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

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
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.

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.

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