On 11/07, Eric Dumazet wrote: > On Tue, Nov 7, 2023 at 10:05 PM Stanislav Fomichev <sdf@xxxxxxxxxx> 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.
