lkml.org 
[lkml]   [2018]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH net 2/2] rxrpc: Fix the data_ready handler
From
Date


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.

\
 
 \ /
  Last update: 2018-10-05 19:45    [W:0.549 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site