From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net 2/2] rxrpc: Fix the data_ready handler Date: Fri, 5 Oct 2018 10:44:36 -0700 Message-ID: References: <80cf9647-ffdf-210a-7b0e-22bf35a57239@gmail.com> <153874697684.18195.15264114363303320691.stgit@warthog.procyon.org.uk> <153874699086.18195.6819270943388841145.stgit@warthog.procyon.org.uk> <15184.1538749081@warthog.procyon.org.uk> <25989.1538757200@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, linux-afs@lists.infradead.org, linux-kernel@vger.kernel.org, Paolo Abeni To: David Howells , Eric Dumazet Return-path: In-Reply-To: <25989.1538757200@warthog.procyon.org.uk> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On 10/05/2018 09:33 AM, David Howells wrote: > Eric Dumazet 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.