Hi Christian, On Tuesday, 8 July 2025 12:09:58 CEST Christian König wrote: > On 08.07.25 10:56, Janusz Krzysztofik wrote: > >> > >> There is no reason to test enabling signaling each of the element in a > >> loop. So there should be something like 4096 calls to the > >> dma_fence_chain_cb function each jumping to the next unsignaled fence and > >> re-installing the callback. > > > > So how building a chain should look like in real use cases? When a user > > builds a chained link of her fence with another fence then may she enable > > signaling on the new chain link? If that other fence occurs a chain link > > then > > who should take care of disabling signaling on it so signaling is enabled > > only > > on the last link of the chain, not leading to a situation similar to what > > we > > have now in the test case? IOW, what's a correct use pattern of > > dma_fence_chain? I can't find that documented anywhere, neither in inline > > docs nor in commit descriptions. > > The dma_fence_chain container is basically a single linked list which allows > to "chain" together multiple dma_fence objects. > > The use cases is to keep only a single fence even when multiple asynchronous > operations have been started. > > So you usually keep only the most recently created dma_fence_chain and > eventually ask that one to signal when you need to wait for all fences inside > the container. > > The tricky part is that since the chain can get very long the implementation > can't use recursion or otherwise we would potentially overflow the kernel > stack. And that needs to be tested and made sure we don't accidentally break > the implementation somehow. > > Keeping all elements of a dma_fence_chain in an array and asking all of them > to signal individually makes no sense, for this use case we have the > dma_fence_array in the first place.
I'm going to submit a patch that drops enabling of signaling on each link of the tested chain, as you suggested. Don't you mind if I add your Suggested- by:? Thanks, Janusz > > Regards, > Christian. > > > > > Thanks, > > Janusz >
