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)
Dec 22 2023, 11:55 PM
Unknown Object (File)
Dec 16 2023, 9:16 AM
Unknown Object (File)
Dec 16 2023, 9:16 AM
Unknown Object (File)
Nov 25 2023, 8:41 PM
Unknown Object (File)
Nov 25 2023, 7:40 AM
Unknown Object (File)
Nov 22 2023, 8:26 PM
Unknown Object (File)
Nov 22 2023, 8:25 PM
Unknown Object (File)
Nov 22 2023, 8:21 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
Lint Not Applicable
Unit
Tests Not Applicable

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.