Messages in this thread | | | Subject | Re: [PATCH net 2/2] rxrpc: Fix the data_ready handler | From | Eric Dumazet <> | Date | Fri, 5 Oct 2018 10:44:36 -0700 |
| |
On 10/05/2018 09:33 AM, David Howells wrote: > Eric Dumazet <eric.dumazet@gmail.com> wrote: > >> 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. > >> 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.
| |