lkml.org 
[lkml]   [2021]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v4 11/13] task_isolation: net: don't flush backlog on CPUs running isolated tasks
From
Date
On Fri, 2021-01-22 at 11:13 -0300, Marcelo Tosatti wrote:
> On Thu, Oct 01, 2020 at 04:47:31PM +0200, Frederic Weisbecker wrote:
> > On Wed, Jul 22, 2020 at 02:58:24PM +0000, Alex Belits wrote:
> > > From: Yuri Norov <ynorov@marvell.com>
> > >
> > > so we don't need to flush it.
> >
> > What guarantees that we have no backlog on it?
>
> From Paolo's work to use lockless reading of
> per-CPU skb lists
>
> https://www.spinics.net/lists/netdev/msg682693.html
>
> It also exposed skb queue length to userspace
>
> https://www.spinics.net/lists/netdev/msg684939.html
>
> But if i remember correctly waiting for a RCU grace
> period was also necessary to ensure no backlog !?!
>
> Paolo would you please remind us what was the sequence of steps?
> (and then also, for the userspace isolation interface, where
> the application informs the kernel that its entering isolated
> mode, is just confirming the queues have zero length is
> sufficient?).

After commit 2de79ee27fdb52626ac4ac48ec6d8d52ba6f9047, for CONFIG_RPS
enabled build, with no RFS in place to ensure backlog will be empty on
CPU X, the user must:
- configure the RPS map on each device before the device goes up to
explicitly exclude CPU X.

If CPU X is isolated after some network device already went up, to
ensure that the backlog will be empty on CPU X the user must:
- configure RPS on all the network device to exclude CPU X (as in the
previous scenario)
- wait a RCU grace period
- wait untill the backlog len on CPU X reported by procfs is 0

Cheers,

Paolo

\
 
 \ /
  Last update: 2021-01-22 17:23    [W:0.118 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site