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

[Leon Romanovsky <leon@kernel.org>]

On Mon, Feb 16, 2026 at 08:48:19AM +0000, Michael Margolin wrote:
> On Sun, Feb 15, 2026 at 07:15:43PM +0200, Leon Romanovsky wrote:
> > On Sun, Feb 15, 2026 at 01:41:22PM +0000, Michael Margolin wrote:
> > > On Thu, Feb 12, 2026 at 06:36:28PM +0200, Leon Romanovsky wrote:
> > > > On Thu, Feb 12, 2026 at 08:52:41AM +0200, Gal Pressman wrote:
> > > > > On 11/02/2026 15:13, Jason Gunthorpe wrote:
> > > > > > On Wed, Feb 11, 2026 at 01:10:48PM +0000, Tom Sela wrote:
> > > > > >> +static ssize_t ah_count_show(struct device *dev, struct device_attribute *attr, char *buf)
> > > > > >> +{
> > > > > >> +	struct efa_dev *efa_dev = pci_get_drvdata(to_pci_dev(dev));
> > > > > >> +
> > > > > >> +	return sysfs_emit(buf, "%lld\n", atomic64_read(&efa_dev->ah_count));
> > > > > >> +}
> > > > > >> +
> > > > > >> +static DEVICE_ATTR_RO(ah_count);
> > > > > >> +
> > > > > >> +int efa_sysfs_init(struct efa_dev *dev)
> > > > > >> +{
> > > > > >> +	struct device *device = &dev->pdev->dev;
> > > > > >> +
> > > > > >> +	if (device_create_file(device, &dev_attr_ah_count))
> > > > > >> +		dev_err(device, "Failed to create AH count sysfs file\n");
> > > > > > 
> > > > > > This is not the right way to use sysfs in rdma drivers.
> > > > > > 
> > > > > > Also we have netlink counters as the prefered approach why are you
> > > > > > using sysfs?
> > > > > 
> > > > > Yes, and EFA already supports stats reporting, the sysfs choice is strange..
> > > > > 
> > > > > BTW, isn't this something that can be added to restrack?
> > > > 
> > > > Unlikely. Most drivers that implement such counters were written long before
> > > > bpftrace became widely used. I don't think modern drivers should carry these
> > > > counters, as they are trivial to collect without requiring any kernel changes.
> > > > This is especially true for EFA, which does not support kverbs.
> > > > 
> > > > Thanks.
> > > 
> > > 
> > > This approach was selected since this case doesn't naturally fit any of
> > > the suggested ideas. It represents usage level of device AH objects
> > > which might be different than the number of kernel objects as usually
> > > covered by restrack count. Stats also doesn't seem as the right place
> > > for this.
> > 
> > How can the kernel and this new counter report a different number of AH
> > objects?
> 
> When application creates multiple AH objects for same peer, the device
> reuses the existing resource and returns its AH number. The new counter
> counts unique AH numbers thus represents the amount of device resources
> currently in use.

https://lore.kernel.org/all/20260215175707.GC12989@unreal

Thanks