Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags

[Stanislav Fomichev]

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.