On 11/07, Eric Dumazet wrote:
On Tue, Nov 7, 2023 at 10:05 PM Stanislav Fomichev sdf@google.com wrote:
I don't understand. We require an elaborate setup to receive devmem cmsgs, why would some random application receive those?
A TCP socket can receive 'valid TCP packets' from many different sources, especially with BPF hooks...
Think of a bonding setup, packets being mirrored by some switches or even from tc.
Better double check than be sorry.
We have not added a 5th component in the 4-tuple lookups, being "is this socket a devmem one".
A mix of regular/devmem skb is supported.
Can we mark a socket as devmem-only? Do we have any use-case for those hybrid setups? Or, let me put it that way: do we expect API callers to handle both linear and non-linear cases correctly? As a consumer of the previous versions of these apis internally, I find all those corner cases confusing :-( Hence trying to understand whether we can make it a bit more rigid and properly defined upstream.
But going back to that MSG_SOCK_DEVMEM flag. If the application is supposed to handle both linear and devmem chucks, why do we need this extra MSG_SOCK_DEVMEM opt-in to signal that it's able to process it? From Mina's reply, it seemed like MSG_SOCK_DEVMEM is there to protect random applications that get misrouted devmem skb. I don't see how returning EFAULT helps in that case.