Re: [PATCH for-next v2 1/5] RDMA/core: Add Completion Counters support

[Doug Ledford <doug.ledford@hpe.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1581 bytes --]

On 4/29/26 8:49 PM, Jason Gunthorpe wrote:
> On Wed, Apr 29, 2026 at 06:50:54PM -0600, Doug Ledford wrote:
>> 1) Make qp attachment optional
>> 2) Extend create verb to differentiate between on-card counter with umem
>> target and in-umem counter
>> 3) Extend create verb to pass in optional trigger or wait capability to
>> perform limited umem updates based upon passed in option
>> 4) Modify read operation so that it can either return the value directly or
>> just trigger an async update of a buffer backed counter (especially useful
>> if the umem counter is on a GPU, is set for a triggered update, and you just
>> want to force an immediate async update)
> 
> After all that is it still a "completion" counter? It seems like it is
> counting something else than a shortcut to polling a CQ?
> 
> Jason
> 

Depends on your definition of "completion counter".  If, by completion, 
you define it narrowly as only queue pair ops completed, then no.  But, 
given that our hardware and the future UET hardware will both be sending 
to many, many destinations via a single send Q on a single QP, just 
counting the QP completions is almost useless for us.  We need 
completions counted to a specific other fabric end point, and aggregate 
counters won't help us with that.  So, from our perspective, yes it's 
still a completion counter, it's just tied to a different element for 
practical purposes.

-- 
Doug Ledford <doug.ledford@hpe.com>
     GPG KeyID: B826A3330E572FDD
     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]