On 11/05, Stanislav Fomichev wrote:
On 11/05, Mina Almasry wrote:
On Wed, Nov 5, 2025 at 9:34 AM Stanislav Fomichev stfomichev@gmail.com wrote:
On 11/04, Bobby Eshleman wrote:
From: Bobby Eshleman bobbyeshleman@meta.com
[..]
+Autorelease Control +~~~~~~~~~~~~~~~~~~~
Have you considered an option to have this flag on the dmabuf binding itself? This will let us keep everything in ynl and not add a new socket option. I think also semantically, this is a property of the binding and not the socket? (not sure what's gonna happen if we have autorelease=on and autorelease=off sockets receiving to the same dmabuf)
I think this thread (and maybe other comments on that patch) is the context that missed your inbox:
https://lore.kernel.org/netdev/aQIoxVO3oICd8U8Q@devvm11784.nha0.facebook.com...
Let us know if you disagree.
Thanks, I did miss that whole v5 because I was OOO, let me take a look!
Thank you for the context!
I think that the current approach is ok, we can go with that, but I wonder whether we can simplify things a bit? What if we prohibit the co-existence of autorelease=on and autorelease=off sockets on the system? The first binding basically locks the kernel path into one way or the other (presumably by using static-branch) and prohibits new bindings that use a different mode. It will let us still keep the mode on the binding and will help us not think about the co-existance (we can also still keep things like one-dmabuf-per-socket restrictions in the new mode, etc).
I think for you, Mina, this should still work? You have a knob to go back to the old mode if needed. At the same time, we keep the UAPI surface smaller and keep the path more simple. Ideally, we can also deprecate the old mode at some point (if you manage to successfully migrate of course). WDYT?