Page MenuHomeFreeBSD

ena: Report RX overrun errors
ClosedPublic

Authored by akiyano_amazon.com on Sat, Apr 25, 9:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Apr 28, 11:12 PM
Unknown Object (File)
Tue, Apr 28, 9:44 AM
Unknown Object (File)
Mon, Apr 27, 11:01 AM
Unknown Object (File)
Mon, Apr 27, 9:49 AM
Unknown Object (File)
Sat, Apr 25, 10:27 PM
Unknown Object (File)
Sat, Apr 25, 10:17 PM
Unknown Object (File)
Sat, Apr 25, 10:16 PM
Subscribers

Details

Summary

Extract rx_overruns from the keep alive descriptor reported by
the device and expose it via sysctl hw stats.

RX overrun errors occur when a packet arrives but there are not
enough free buffers in the RX ring to receive it.

Submitted by: David Arinzon <darinzon@amazon.com>
MFC after: 2 weeks
Sponsored by: Amazon, Inc.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

akiyano_amazon.com planned changes to this revision.
akiyano_amazon.com created this revision.

This looks fine, but why are we using counters for this? Counters are useful when you have many CPUs each incrementing a counter -- they increment their own per-CPU version and then reading the counter adds up all of the per-CPU counters -- but I think this is just a single 64-bit value being recorded.

The change looks fine but after 15.1 is out the door we should reconsider whether counters are the right API to be using for this.

This revision is now accepted and ready to land.Sat, Apr 25, 10:13 PM

This looks fine, but why are we using counters for this? Counters are useful when you have many CPUs each incrementing a counter -- they increment their own per-CPU version and then reading the counter adds up all of the per-CPU counters -- but I think this is just a single 64-bit value being recorded.

The change looks fine but after 15.1 is out the door we should reconsider whether counters are the right API to be using for this.

Thanks for the review. You're right — all of our stats currently use counter_u64, even the ones that
are just single values from the device. We'll look into using a more appropriate type for the keep-
alive stats in a future cleanup.

This revision was automatically updated to reflect the committed changes.