On Wed, Nov 05, 2025 at 09:34:03AM -0800, Stanislav Fomichev 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)
This was our initial instinct too and was the implementation in the prior version, but we opted for a socket-based property because it simplifies backwards compatibility with multi-binding steering rules. In this case, where bindings may have different autorelease settings, the recv path would need to error out once any binding with different autorelease value was detected, because the dont_need path doesn't have any context to know if any specific token is part of the socket's xarray (autorelease=on) or part of the binding->vec (autorelease=off).
At the socket level we can just prevent the mode switch by counting outstanding references... to do this at the binding level, I think we have to revert back to the ethtool approach we experimented with earlier (trying to resolve steering rules to queues, and then check their binding->autorelease values and make sure they are consistent).
This should work out off the box for mixed-modes, given then outstanding ref rule.
Probably should add a test for specifically that...
Best, Bobby