On Wed, 4 Sep 2024 15:13:54 +0200 Alexander Lobakin wrote: > > 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. > > Lorenzo will try as he wrote. I can only add that in my old tree, I > factored out GRO bits and used them here just as you wrote. The perf was > the same, but the diffstat was several hundred lines only to factor out > stuff, while here the actual switch to NAPI removes more lines than > adds, also custom kthread logic is gone etc. It just looks way more > elegant and simple. Once again we seem to be arguing whether lower LoC is equivalent to better code? :) If we can use backlog NAPI it hopefully won't be as long. Maybe other, better approaches are within reach, too. > I could say that gro_cells also "abuses" NAPI the same way, don't you > think? "same way"? :] Does it allocate a fake netdev, use NAPI as a threading abstraction or add extra fields to napi_struct ? If other maintainers disagree I won't be upset, but I'm worried that letting NAPI grow into some generic SW abstraction with broad use cases will hinder the ongoing queue config efforts. > But nobody ever objected :>
