Re: [PATCH for-next] RDMA/efa: Add AH usage counter with sysfs exposure

[Leon Romanovsky <leon@kernel.org>]

On Mon, Feb 16, 2026 at 11:08:53AM +0000, Michael Margolin wrote:
> On Sun, Feb 15, 2026 at 07:57:07PM +0200, Leon Romanovsky wrote:
> > On Sun, Feb 15, 2026 at 07:23:41PM +0200, Gal Pressman wrote:
> > > On 15/02/2026 19:15, Leon Romanovsky wrote:
> > > >> Stats also doesn't seem as the right place
> > > >> for this.
> > > 
> > > Because?
> > > 
> > > > 
> > > > How can the kernel and this new counter report a different number of AH
> > > > objects?
> > > > 
> > > >>
> > > >> In a followup series we will suggest netlink counters extension to
> > > >> support driver specific resources.
> > > > 
> > > > bpftrace is generally the right tool, unless you can detail why it does not  
> > > > fit your specific debugging scenario.
> > > 
> > > I don't understand, how do you use bpftrace for this use case?
> > > 
> > > Once you get to debug a system in a certain state, bpftrace won't help
> > > you see events that happened in the past. You won't be able to know how
> > > many AH were created.
> > 
> > Their proposed counter can be implemented by counting calls to
> > efa_com_create_ah minus calls to efa_com_destroy_ah.
> > 
> > You have two ways to get it:
> > 1. run bfptrace with your reproducer
> > 2. check FW to get their internal counter
> > 
> 
> Calls to efa_com_create_ah minus calls to efa_com_destroy_ah will not
> always result in correct number of consumed device resources as multiple
> calls to efa_com_create_ah can return the same AH number.

bpftrace supports map and can count unique ids.

> 
> Additionally we are looking to expose this info to customers without
> requiring a kernel rebuild or the use of debug tools, similar to how
> device and port statistics can be read in sysfs or through the rdma
> tool.

BPF doesn't require any kernel rebuild. It works out-of-the-box on even
old kernels.

Thanks

> 
> Michael
>