On Mon, Jan 26, 2026 at 06:44:40PM -0800, Jakub Kicinski wrote: > On Mon, 26 Jan 2026 18:30:45 -0800 Bobby Eshleman wrote: > > > > 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? > > > > > > > > > > I don't like: > > > - the fact that we have to add the binding to a socket (extra field) > > > - single socket can only serve single binding, there's no technical > > > reason for this really, AFAICT, just the fact that we have a single > > > pointer in the sock struct > > > > The core reason is that sockets lose the ability to map a given token to > > a given binding by no longer storing the niov ptr. > > > > One proposal I had was to encode some number of bits in the token that > > can be used to lookup the binding in an array, I could reboot that > > approach. > > > > With 32 bits, we can represent: > > > > dmabuf max size = 512 GB, max dmabuf count = 8 > > dmabuf max size = 256 GB, max dmabuf count = 16 > > dmabuf max size = 128 GB, max dmabuf count = 32 > > > > etc... > > > > Then, if the dmabuf count encoding space is exhausted, the socket would > > have to wait until the user returns all of the tokens from one of the > > dmabufs and frees the ID (or err out is another option). > > > > This wouldn't change adding a field to the socket, we'd have to add one > > or two more for allocating the dmabuf ID and fetching the dmabuf with > > it. But it does fix the single binding thing. > > I think the bigger problem (than space exhaustion) is that we'd also > have some understanding of permissions. If an application guesses > the binding ID of another app it can mess up its buffers. ENOBUENO..
I was thinking it would be per-socket, effectively: sk->sk_devmem_info.bindings[binding_id_from_token(token)] So sockets could only access those that they have already recv'd on.
