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@xxxxxxxxxxx> > > > > > > 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
