On 6/9/26 11:44, SHANMUGAM, SRINIVASAN wrote: > Public > > Hi Christian, > >> -----Original Message----- >> From: Koenig, Christian <[email protected]> >> Sent: Friday, June 5, 2026 6:56 PM >> To: SHANMUGAM, SRINIVASAN <[email protected]>; >> Deucher, Alexander <[email protected]> >> Cc: [email protected] >> Subject: Re: [PATCH v9 06/11] drm/amdgpu: Make EVENTFD subscriptions queue- >> aware >> >> On 6/3/26 18:33, Srinivasan Shanmugam wrote: >>> The current EVENTFD manager matches subscriptions only by event >>> identifier. That is enough for coarse notification, but it does not >>> support the queue-scoped routing needed by queue completion style >>> events. >>> >>> Extend the subscription key from a single event identifier to the pair >>> (event_type, queue_id). >>> >>> For device/GPU-scoped events, queue_id is 0. For queue-scoped events, >>> queue_id selects the queue-specific subscription. >>> >>> EVENTFD remains notification-only. >>> >>> Also fix the queue-aware bind path to compute the packed subscription >>> key before lookup/insert, and allow fd 0 by rejecting only negative >>> file descriptors. >>> >>> This change keeps the existing manager design and binding model >>> intact, while making queue_id meaningful for queue-scoped wakeups. >> >> Yeah that doesn't work like this. >> >> The queue_id is just an identifier for the UAPI and can be re-used. >> >> So you can't put that as key in the amdgpu_eventfd_id structure. >> >> I suggest to convert the queue_id into the global doorbell id or put the >> eventfd >> manager on the queue itself instead of the fpriv. > > I understand the issue now. Since queue_id is just a UAPI handle and can be > reused after a queue is destroyed, I understand that we should use the > refcounted queue object instead of storing queue_id in the EVENTFD > subscription. > > One clarification pls: would you prefer the EVENTFD subscription itself to > hold the queue reference and release it during unbind/teardown, or should > USERQ resolve queue_id to the queue object and keep EVENTFD as a generic > notification layer?
As far as I can see the eventfd handling must hold a reference to the queue structure or otherwise we will run into problems. Just make sure that when the queue id is released that we tell this the eventfd manager so that we can free those references as well. Regards, Christian. > > I can implement either approach. I just wanted to confirm which direction you > had in mind. > > Best regards, > Srini > > >> >> Regards, >> Christian.
