> > On Fri, 30 Aug 2024 18:24:59 +0200 Alexander Lobakin wrote: > > > * patch 4: switch cpumap from a custom kthread to a CPU-pinned > > > threaded NAPI; > > > > Could you try to use the backlog NAPI? Allocating a fake netdev and > > using NAPI as a threading abstraction feels like an abuse. Maybe try > > to factor out the necessary bits? What we want is using the per-cpu > > caches, and feeding GRO. None of the IRQ related NAPI functionality > > fits in here. > > I was thinking allocating a fake netdev to use NAPI APIs is quite a common > approach, but sure, I will looking into it. From a first glance I think we could use the backlog NAPI APIs here in order to avoid allocating a dummy netdev. We could implement a similar approach I used for the cpumap + gro_cell here [0]. In particular, the cpumap kthread pinned on cpu 'n' can schedule the backlog NAPI associated to cpu 'n'. However according to my understanding it seems the backlog NAPI APIs (in process_backlog()) do not support GRO, right? Am I missing something? Regards, Lorenzo [0] https://github.com/LorenzoBianconi/bpf-next/commit/a4b8264d5000ecf016da5a2dd9ac302deaf38b3e > > Regards, > Lorenzo
Attachment:
signature.asc
Description: PGP signature
