[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201121163136.024d636c@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date: Sat, 21 Nov 2020 16:31:36 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Wei Wang <weiwan@...gle.com>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
Eric Dumazet <edumazet@...gle.com>,
Felix Fietkau <nbd@....name>, Paolo Abeni <pabeni@...hat.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Hillf Danton <hdanton@...a.com>
Subject: Re: [PATCH net-next v3 1/5] net: implement threaded-able napi poll
loop support
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.
> + /* if the device is initializing, nothing todo */
> + if (test_bit(__LINK_STATE_START, &n->dev->state))
> + return 0;
> +
> + napi_thread_stop(n);
> + napi_thread_start(n);
> + return 0;
> +}
> +EXPORT_SYMBOL(napi_set_threaded);
Why was this exported? Do we still need that?
Please rejig the patches into a reviewable form. You can use the
Co-developed-by tag to give people credit on individual patches.
Powered by blists - more mailing lists