On Tue, Sep 27, 2022 at 11:18 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Tue, 27 Sep 2022 10:54:49 -0700 Eric Dumazet wrote: > > On Tue, Sep 27, 2022 at 6:28 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > We tell driver developers to always pass NAPI_POLL_WEIGHT > > > as the weight to netif_napi_add(). This may be confusing > > > to newcomers, drop the weight argument, those who really > > > need to tweak the weight can use netif_napi_add_weight(). > > > > > > Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> > > > > Sure, but this kind of patch makes backports harder. > > Not sure how confused are newcomers about this NAPI_POLL_WEIGHT.... > > I maintained this patch in my tree for a couple of releases (because > I was waiting for the _weight() version to propagate to non-netdev > trees) and the conflicts were minor. Three or so cases of new features > added to drivers which touched the NAPI calls (WiFi and embedded) and > the strlcpy -> strscpy patch, and, well, why did we take that in if we > worry about backports... > > NAPI weight was already dead when I started hacking on the kernel > 10 years ago. I don't think it's reasonable to keep dead stuff > in our APIs for backport's sake. Adding Jiri to CC in case I need > someone to back me up :) > > The idea for this patch came because I was reviewing a driver which > was trying to do something clever with the weight. > No hard feelings, but the recent removal of netif_tx_napi_add() added extra work for some of us ;) Keeping around few helpers to keep API a bit stable would help I think.
