On 01/21, Jakub Kicinski wrote: > On Wed, 21 Jan 2026 19:25:27 -0800 Bobby Eshleman wrote: > > > > That is correct, neither is true. If the two sockets share a binding the > > > > kernel doesn't care which socket received the token or which one > > > > returned it. No token <> socket association. There is no > > > > queued-but-not-read race either. If any tokens are not returned, as long > > > > as all of the binding references are eventually released and all sockets > > > > that used the binding are closed, then all references will be accounted > > > > for and everything cleaned up. > > > > > > Naming is hard, but I wonder whether the whole feature wouldn't be > > > better referred to as something to do with global token accounting > > > / management? AUTORELEASE makes sense but seems like focusing on one > > > particular side effect. > > > > Good point. The only real use case for autorelease=on is for backwards > > compatibility... so I thought maybe DEVMEM_A_DMABUF_COMPAT_TOKEN > > or DEVMEM_A_DMABUF_COMPAT_DONTNEED would be clearer? > > Hm. Maybe let's return to naming once we have consensus on the uAPI. > > Does everyone think that pushing this via TCP socket opts still makes > sense, even tho in practice the TCP socket is just how we find the > binding?
I'm not a fan of the existing cmsg scheme, but we already have userspace using it, so getting more performance out of it seems like an easy win?
