Page MenuHomeFreeBSD

sfxge: implement interface statistics shown by netstat
ClosedPublic

Authored by arybchik on Nov 30 2015, 12:54 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sep 10 2025, 4:44 AM
Unknown Object (File)
Sep 6 2025, 8:54 AM
Unknown Object (File)
Aug 3 2025, 8:40 AM
Unknown Object (File)
Aug 2 2025, 10:57 PM
Unknown Object (File)
Jul 28 2025, 7:15 PM
Unknown Object (File)
Jul 28 2025, 2:58 AM
Unknown Object (File)
Jul 26 2025, 1:12 PM
Unknown Object (File)
Jul 26 2025, 12:13 PM
Subscribers

Details

Summary

It is a direct commit to stable/10 since HW-assisted statistics
support differs in head (uses if_get_counter callback).

PR: 202907
Submitted by: Boris Misenov <Boris.Misenov at oktetlabs.ru>
Sponsored by: Solarflare Communications, Inc.

Test Plan

Driver build tested, driver loaded/unloaded.
'netstat -I sfxge0 -w 1' statistics checked under traffic

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 1341
Build 1346: arc lint + arc unit

Event Timeline

arybchik retitled this revision from to sfxge: implement interface statistics shown by netstat.
arybchik updated this object.
arybchik edited the test plan for this revision. (Show Details)
arybchik added reviewers: gnn, np, philip, bz.

I'd change the default number of ticks to 100 (1Hz) rather than 10 (10Hz)

stable/10/sys/dev/sfxge/sfxge.h
125

Isn't this a bit too frequent?

I agree with @gnn that every 10 ticks is too frequent. I'd accept it as a default if there were a sysctl to make it less frequent though. But just making it every 100 ticks is probably easier and good enough.

I also worry about not taking any locks in sfxge_tx_get_drops(). It's just statistics as the comment points out, but if monitoring reports drops as unpredictable, one might spend a lot of time chasing a non-existent network issue? Probably not a problem though.

Thanks, I think I'll add tunable to control stats polling period with 100 as a default.

Right now sfxge driver supports amd64 only and these statistics use unsigned long type which is updated atomically (I mean update cannot be split into two assembler operations). Also it is a statistics which just grow, so we either pick up old or new value. Maybe I'm missing something.

I wasn't too concerned about atomicity. I was a little worried about reading a lower value after having read a higher value. But such inconsistencies (if they ever even happen) will disappear quickly. I wouldn't worry about it. This is fine.

arybchik edited edge metadata.

Added tunable and set changed default polling period to 100

This revision was automatically updated to reflect the committed changes.