On Mon, Nov 6, 2023 at 5:06 PM Stanislav Fomichev sdf@google.com wrote: [..]
And the socket has to know this association; otherwise those tokens are useless since they don't carry anything to identify the dmabuf.
I think my other issue with MSG_SOCK_DEVMEM being on recvmsg is that it somehow implies that I have an option of passing or not passing it for an individual system call.
You do have the option of passing it or not passing it per system call. The MSG_SOCK_DEVMEM says the application is willing to receive devmem cmsgs - that's all. The application doesn't get to decide whether it's actually going to receive a devmem cmsg or not, because that's dictated by the type of skb that is present in the receive queue, and not up to the application. I should explain this in the commit message...
What would be the case of passing it or not passing it? Some fallback to the host memory after flow steering update? Yeah, would be useful to document those constrains. I'd lean on starting stricter and relaxing those conditions if we find the use-cases.
MSG_SOCK_DEVMEM (or its replacement SOCK_DEVMEM or SO_SOCK_DEVMEM), just says that the application is able to receive devmem cmsgs and will parse them. The use case for not setting that flag is existing applications that are not aware of devmem cmsgs. I don't want those applications to think they're receiving data in the linear buffer only to find out that the data is in devmem and they ignored the devmem cmsg.
So, what happens:
- MSG_SOCK_DEVMEM provided and next skb in the queue is devmem: application receives cmsgs. - MSG_SOCK_DEVMEM provided and next skb in the queue is non-devmem: application receives in the linear buffer. - MSG_SOCK_DEVMEM not provided and net skb is devmem: application receives EFAULT. - MSG_SOCK_DEVMEM not provided and next skb is non-devmem: application receives in the linear buffer.
My bad on not including some docs about this. The next version should have the commit message beefed up to explain all this, or a docs patch.