On Mon, Nov 23, 2020 at 10:56 AM Jakub Kicinski [off-list ref] wrote:

On Sat, 21 Nov 2020 18:23:33 -0800 Wei Wang wrote:

quoted

On Sat, Nov 21, 2020 at 4:31 PM Jakub Kicinski [off-list ref] wrote:

quoted

On Wed, 18 Nov 2020 11:10:05 -0800 Wei Wang wrote:

quoted

+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.

Yes. That is true. The bit position is dependent on the driver implementation.

If anyone has a strong use for it now, please let us know.

OK. Will change it to per dev control if no one objects.