On 10/05/2018 09:33 AM, David Howells wrote:

Eric Dumazet [off-list ref] wrote:

quoted

sk_data_ready is not meant to process packets, it is meant to signal
to another entity (preferably running in process context and thus with proper
schedule points, and not blocking BH) that there is data ready to be consumed.

The issue is that I need to route the packets to the appropriate call, and the
BH appears to be the right place to do this, especially as I can quickly parse
and discard certain types of packet right there.

If I move all of this to process context then that adds extra context switches
between the routing process and the destination process.

quoted

Under DOS, it is possible multiple cpus will sk_data_ready in parallel.

Ummm...  I've been led to believe that sk_data_ready will *not* be called in
parallel and that the code it calls can assume non-reentrancy.  Is this not
the case.

Certainly not for UDP.

TCP input processing uses the socket lock, but UDP is fully parallel.

What about the patch I attached, whereby I use the encap_rcv() hook.  Do you
say that won't work?

I am kind of busy today, will look at it next week.