On Sat, 21 Nov 2020 18:23:33 -0800 Wei Wang wrote: > On Sat, Nov 21, 2020 at 4:31 PM Jakub Kicinski <[email protected]> wrote: > > On Wed, 18 Nov 2020 11:10:05 -0800 Wei Wang wrote: > > > +int napi_set_threaded(struct napi_struct *n, bool threaded) > > > +{ > > > + ASSERT_RTNL(); > > > + > > > + if (n->dev->flags & IFF_UP) > > > + return -EBUSY; > > > + > > > + if (threaded == !!test_bit(NAPI_STATE_THREADED, &n->state)) > > > + return 0; > > > + if (threaded) > > > + set_bit(NAPI_STATE_THREADED, &n->state); > > > + else > > > + clear_bit(NAPI_STATE_THREADED, &n->state); > > > > Do we really need the per-NAPI control here? Does anyone have use cases > > where that makes sense? The user would be guessing which NAPI means > > which queue and which bit, currently. > > Thanks for reviewing this. > I think one use case might be that if the driver uses separate napi > for tx and rx, one might want to only enable threaded mode for rx, and > leave tx completion in interrupt mode.
Okay, but with separate IRQs/NAPIs that's really a guessing game in terms of NAPI -> bit position. I'd rather we held off on the per-NAPI control. If anyone has a strong use for it now, please let us know.
