On 19/02/2025 03:50, Jon Pan-Doh wrote:
On Mon, Feb 17, 2025 at 5:31 AM Karolina Stolarek
<karolina.stolarek@xxxxxxxxxx> wrote:
I don't think it's neccessary to keep ratelimits in a separate directory
when we decided to we keep the rest of AER attributes at the dev level.
My motivation for this is that there may be more AER sysfs attributes we want to
expose. An example being OCP Fault Management roadmap which aims to have
userspace manage/enforce AER settings (set/get PCIE AER regs) for datacenter
repairability.
Given the permanence of sysfs entries, I think that it is reasonable
to create a new
directory to make AER sysfs attributes more extensible.
OK, I see what you mean. Maybe I was just unhappy with the naming but,
to be completely honest, "aer_ratelimit" isn't an option, so I won't
propose it as an alternative. Let's leave it as it is for now.
Good catch. IRQ verbiage slipped in from v1. How's this:
These attributes show up under all the devices that are AER capable.
They allow configuration of the rate at which AER errors are reported,
with each of them dedicated to one error type (correctable or uncorrectable).
Perfect
The convention is that sysfs files should provide one value per file. It
won't be just people interacting with this interface, but scripts as
well. Parsing such a string is a hassle. As we can only change the burst
of the ratelimit, I'd simply emit pdev->aer_report->ratelimit.burst.
Ack. Will update in v3 and add explicit mention of ratelimit interval
in sysfs-bus-pci-devices-aer_stats so context is still there.
Good!
All the best,
Karolina
