lkml.org 
[lkml]   [2020]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: liquidio vs smp_call_function_single_async()
Date
> From: Peter Zijlstra <peterz@infradead.org>
> Sent: Monday, June 8, 2020 6:05 AM
> To: Derek Chickles <dchickles@marvell.com>; Satananda Burla
> <sburla@marvell.com>; Felix Manlunas <fmanlunas@marvell.com>
> Cc: frederic@kernel.org; linux-kernel@vger.kernel.org;
> davem@davemloft.net; kuba@kernel.org; netdev@vger.kernel.org
> Subject: liquidio vs smp_call_function_single_async()
>
> Hi,
>
> I'm going through the smp_call_function_single_async() users, and stumbled
> over your liquidio thingy. It does:
>
> call_single_data_t *csd = &droq->csd;
>
> csd->func = napi_schedule_wrapper;
> csd->info = &droq->napi;
> csd->flags = 0;
>
> smp_call_function_single_async(droq->cpu_id, csd);
>
> which is almost certainly a bug. What guarantees that csd is unused when
> you do this? What happens, if the remote CPU is already running RX and
> consumes the packets before the IPI lands, and then this CPU gets another
> interrupt.
>
> AFAICT you then call this thing again, causing list corruption.

Hi Peter,

I think you're right that this might be a functional bug, but it won't cause list
corruption. We don't rely on the IPI to process packets; only to move NAPI
processing to another CPU. There are separate register counters that indicate
if and how many new packets have arrived, that will be re-read once it
executes.

I think a patch to check if NAPI is already scheduled would address the
unexpected rescheduling issue here. Otherwise, it can probably live as is,
as there is no harm.

Thanks,
Derek

\
 
 \ /
  Last update: 2020-06-11 23:49    [W:0.042 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site