The idea of moving the napi poll process out of softirq context to a
kernel thread based context is not new.
Paolo Abeni and Hannes Frederic Sowa have proposed patches to move napi
poll to kthread back in 2016. And Felix Fietkau has also proposed
patches of similar ideas to use workqueue to process napi poll just a
few weeks ago.
The main reason we'd like to push forward with this idea is that the
scheduler has poor visibility into cpu cycles spent in softirq context,
and is not able to make optimal scheduling decisions of the user threads.
For example, we see in one of the application benchmark where network
load is high, the CPUs handling network softirqs has ~80% cpu util. And
user threads are still scheduled on those CPUs, despite other more idle
cpus available in the system. And we see very high tail latencies. In this
case, we have to explicitly pin away user threads from the CPUs handling
network softirqs to ensure good performance.
With napi poll moved to kthread, scheduler is in charge of scheduling both
the kthreads handling network load, and the user threads, and is able to
make better decisions. In the previous benchmark, if we do this and we
pin the kthreads processing napi poll to specific CPUs, scheduler is
able to schedule user threads away from these CPUs automatically.
And the reason we prefer 1 kthread per napi, instead of 1 workqueue
entity per host, is that kthread is more configurable than workqueue,
and we could leverage existing tuning tools for threads, like taskset,
chrt, etc to tune scheduling class and cpu set, etc. Another reason is
if we eventually want to provide busy poll feature using kernel threads
for napi poll, kthread seems to be more suitable than workqueue.
Furthermore, for large platforms with 2 NICs attached to 2 sockets,
kthread is more flexible to be pinned to different sets of CPUs.
In this patch series, I revived Paolo and Hannes's patch in 2016 and
made modifications. Then there are changes proposed by Felix, Jakub,
Paolo and myself on top of those, with suggestions from Eric Dumazet.
In terms of performance, I ran tcp_rr tests with 1000 flows with
various request/response sizes, with RFS/RPS disabled, and compared
performance between softirq vs kthread vs workqueue (patchset proposed
by Felix Fietkau).
Host has 56 hyper threads and 100Gbps nic, 8 rx queues and only 1 numa
node. All threads are unpinned.
req/resp QPS 50%tile 90%tile 99%tile 99.9%tile
softirq 1B/1B 2.75M 337us 376us 1.04ms 3.69ms
kthread 1B/1B 2.67M 371us 408us 455us 550us
workq 1B/1B 2.56M 384us 435us 673us 822us
softirq 5KB/5KB 1.46M 678us 750us 969us 2.78ms
kthread 5KB/5KB 1.44M 695us 789us 891us 1.06ms
workq 5KB/5KB 1.34M 720us 905us 1.06ms 1.57ms
softirq 1MB/1MB 11.0K 79ms 166ms 306ms 630ms
kthread 1MB/1MB 11.0K 75ms 177ms 303ms 596ms
workq 1MB/1MB 11.0K 79ms 180ms 303ms 587ms
When running workqueue implementation, I found the number of threads
used is usually twice as much as kthread implementation. This probably
introduces higher scheduling cost, which results in higher tail
latencies in most cases.
I also ran an application benchmark, which performs fixed qps remote SSD
read/write operations, with various sizes. Again, both with RFS/RPS
disabled.
The result is as follows:
op_size QPS 50%tile 95%tile 99%tile 99.9%tile
softirq 4K 572.6K 385us 1.5ms 3.16ms 6.41ms
kthread 4K 572.6K 390us 803us 2.21ms 6.83ms
workq 4k 572.6K 384us 763us 3.12ms 6.87ms
softirq 64K 157.9K 736us 1.17ms 3.40ms 13.75ms
kthread 64K 157.9K 745us 1.23ms 2.76ms 9.87ms
workq 64K 157.9K 746us 1.23ms 2.76ms 9.96ms
softirq 1M 10.98K 2.03ms 3.10ms 3.7ms 11.56ms
kthread 1M 10.98K 2.13ms 3.21ms 4.02ms 13.3ms
workq 1M 10.98K 2.13ms 3.20ms 3.99ms 14.12ms
In this set of tests, the latency is predominant by the SSD operation.
Also, the user threads are much busier compared to tcp_rr tests. We have
to pin the kthreads/workqueue threads to limit to a few CPUs, to not
disturb user threads, and provide some isolation.
Changes since v5:
Removed ASSERT_RTNL() from napi_set_threaded() and removed rtnl_lock()
operation from napi_enable().
Changes since v4:
Recorded the threaded setting in dev and restore it in napi_enable().
Changes since v3:
Merged and rearranged patches in a logical order for easier review.
Changed sysfs control to be per device.
Changes since v2:
Corrected typo in patch 1, and updated the cover letter with more
detailed and updated test results.
Changes since v1:
Replaced kthread_create() with kthread_run() in patch 5 as suggested by
Felix Fietkau.
Changes since RFC:
Renamed the kthreads to be napi/<dev>-<napi_id> in patch 5 as suggested
by Hannes Frederic Sowa.
Felix Fietkau (1):
net: extract napi poll functionality to __napi_poll()
Wei Wang (2):
net: implement threaded-able napi poll loop support
net: add sysfs attribute to control napi threaded mode
include/linux/netdevice.h | 14 +--
net/core/dev.c | 176 +++++++++++++++++++++++++++++++++++---
net/core/net-sysfs.c | 63 ++++++++++++++
3 files changed, 236 insertions(+), 17 deletions(-)
--
2.30.0.284.gd98b1dd5eaa7-goog
This patch allows running each napi poll loop inside its own
kernel thread.
The threaded mode could be enabled through napi_set_threaded()
api, and does not require a device up/down. The kthread gets
created on demand when napi_set_threaded() is called, and gets
shut down eventually in napi_disable().
Once that threaded mode is enabled and the kthread is
started, napi_schedule() will wake-up such thread instead
of scheduling the softirq.
The threaded poll loop behaves quite likely the net_rx_action,
but it does not have to manipulate local irqs and uses
an explicit scheduling point based on netdev_budget.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 12 ++--
net/core/dev.c | 113 ++++++++++++++++++++++++++++++++++++++
2 files changed, 118 insertions(+), 7 deletions(-)
@@ -358,6 +359,7 @@ enum {NAPI_STATE_NO_BUSY_POLL,/* Do not add in napi_hash, no busy polling */NAPI_STATE_IN_BUSY_POLL,/* sk_busy_loop() owns this NAPI */NAPI_STATE_PREFER_BUSY_POLL,/* prefer busy-polling over softirq processing*/+NAPI_STATE_THREADED,/* The poll is performed inside its own thread*/};enum{
@@ -1493,6 +1494,36 @@ void netdev_notify_peers(struct net_device *dev)}EXPORT_SYMBOL(netdev_notify_peers);+staticintnapi_threaded_poll(void*data);++staticintnapi_kthread_create(structnapi_struct*n)+{+interr=0;++/* Create and wake up the kthread once to put it in+*TASK_INTERRUPTIBLEmodetoavoidtheblockedtask+*warningandworkwithloadavg.+*/+n->thread=kthread_run(napi_threaded_poll,n,"napi/%s-%d",+n->dev->name,n->napi_id);+if(IS_ERR(n->thread)){+err=PTR_ERR(n->thread);+pr_err("kthread_run failed with err %d\n",err);+n->thread=NULL;+}++returnerr;+}++staticvoidnapi_kthread_stop(structnapi_struct*n)+{+if(!n->thread)+return;+kthread_stop(n->thread);+clear_bit(NAPI_STATE_THREADED,&n->state);+n->thread=NULL;+}+staticint__dev_open(structnet_device*dev,structnetlink_ext_ack*extack){conststructnet_device_ops*ops=dev->netdev_ops;
@@ -4252,6 +4283,11 @@ int gro_normal_batch __read_mostly = 8;staticinlinevoid____napi_schedule(structsoftnet_data*sd,structnapi_struct*napi){+if(test_bit(NAPI_STATE_THREADED,&napi->state)){+wake_up_process(napi->thread);+return;+}+list_add_tail(&napi->poll_list,&sd->poll_list);__raise_softirq_irqoff(NET_RX_SOFTIRQ);}
From: Felix Fietkau <nbd@nbd.name>
This commit introduces a new function __napi_poll() which does the main
logic of the existing napi_poll() function, and will be called by other
functions in later commits.
This idea and implementation is done by Felix Fietkau [off-list ref] and
is proposed as part of the patch to move napi work to work_queue
context.
This commit by itself is a code restructure.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Wei Wang <redacted>
---
net/core/dev.c | 35 +++++++++++++++++++++++++----------
1 file changed, 25 insertions(+), 10 deletions(-)
@@ -6772,15 +6772,10 @@ void __netif_napi_del(struct napi_struct *napi)}EXPORT_SYMBOL(__netif_napi_del);-staticintnapi_poll(structnapi_struct*n,structlist_head*repoll)+staticint__napi_poll(structnapi_struct*n,bool*repoll){-void*have;intwork,weight;-list_del_init(&n->poll_list);--have=netpoll_poll_lock(n);-weight=n->weight;/* This NAPI_STATE_SCHED test is for avoiding a race
@@ -6800,7 +6795,7 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)n->poll,work,weight);if(likely(work<weight))-gotoout_unlock;+returnwork;/* Drivers must not modify the NAPI state if they*consumetheentireweight.Insuchcasesthiscode
@@ -6809,7 +6804,7 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)*/if(unlikely(napi_disable_pending(n))){napi_complete(n);-gotoout_unlock;+returnwork;}/* The NAPI context has more processing work, but busy-polling
This patch adds a new sysfs attribute to the network device class.
Said attribute provides a per-device control to enable/disable the
threaded mode for all the napi instances of the given network device.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 28 +++++++++++++++++
net/core/net-sysfs.c | 63 +++++++++++++++++++++++++++++++++++++++
3 files changed, 93 insertions(+)
@@ -6754,6 +6754,34 @@ static int napi_set_threaded(struct napi_struct *n, bool threaded)returnerr;}+staticvoiddev_disable_threaded_all(structnet_device*dev)+{+structnapi_struct*napi;++list_for_each_entry(napi,&dev->napi_list,dev_list)+napi_set_threaded(napi,false);+}++intdev_set_threaded(structnet_device*dev,boolthreaded)+{+structnapi_struct*napi;+intret;++dev->threaded=threaded;+list_for_each_entry(napi,&dev->napi_list,dev_list){+ret=napi_set_threaded(napi,threaded);+if(ret){+/* Error occurred on one of the napi,+*resetthreadedmodeonallnapi.+*/+dev_disable_threaded_all(dev);+break;+}+}++returnret;+}+voidnetif_napi_add(structnet_device*dev,structnapi_struct*napi,int(*poll)(structnapi_struct*,int),intweight){
@@ -538,6 +538,68 @@ static ssize_t phys_switch_id_show(struct device *dev,}staticDEVICE_ATTR_RO(phys_switch_id);+staticssize_tthreaded_show(structdevice*dev,+structdevice_attribute*attr,char*buf)+{+structnet_device*netdev=to_net_dev(dev);+structnapi_struct*n;+boolenabled;+intret;++if(!rtnl_trylock())+returnrestart_syscall();++if(!dev_isalive(netdev)){+ret=-EINVAL;+gotounlock;+}++if(list_empty(&netdev->napi_list)){+ret=-EOPNOTSUPP;+gotounlock;+}++/* Only return true if all napi have threaded mode.+*Theinconsistencycouldhappenwhenthedevicedrivercalls+*napi_disable()/napi_enable()withdev->threadedsettotrue,+*butnapi_kthread_create()fails.+*Wereturnfalseinthiscasetoremindtheuserthatoneor+*morenapididnothavethreadedmodeenabledproperly.+*/+list_for_each_entry(n,&netdev->napi_list,dev_list){+enabled=!!test_bit(NAPI_STATE_THREADED,&n->state);+if(!enabled)+break;+}++ret=sprintf(buf,fmt_dec,enabled);++unlock:+rtnl_unlock();+returnret;+}++staticintmodify_napi_threaded(structnet_device*dev,unsignedlongval)+{+structnapi_struct*napi;+intret;++if(list_empty(&dev->napi_list))+return-EOPNOTSUPP;++ret=dev_set_threaded(dev,!!val);++returnret;+}++staticssize_tthreaded_store(structdevice*dev,+structdevice_attribute*attr,+constchar*buf,size_tlen)+{+returnnetdev_store(dev,attr,buf,len,modify_napi_threaded);+}+staticDEVICE_ATTR_RW(threaded);+staticstructattribute*net_class_attrs[]__ro_after_init={&dev_attr_netdev_group.attr,&dev_attr_type.attr,
From: Alexander Duyck <hidden> Date: 2021-01-15 03:15:37
On Thu, Jan 14, 2021 at 4:33 PM Wei Wang [off-list ref] wrote:
quoted hunk
This patch allows running each napi poll loop inside its own
kernel thread.
The threaded mode could be enabled through napi_set_threaded()
api, and does not require a device up/down. The kthread gets
created on demand when napi_set_threaded() is called, and gets
shut down eventually in napi_disable().
Once that threaded mode is enabled and the kthread is
started, napi_schedule() will wake-up such thread instead
of scheduling the softirq.
The threaded poll loop behaves quite likely the net_rx_action,
but it does not have to manipulate local irqs and uses
an explicit scheduling point based on netdev_budget.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 12 ++--
net/core/dev.c | 113 ++++++++++++++++++++++++++++++++++++++
2 files changed, 118 insertions(+), 7 deletions(-)
@@ -358,6 +359,7 @@ enum {NAPI_STATE_NO_BUSY_POLL,/* Do not add in napi_hash, no busy polling */NAPI_STATE_IN_BUSY_POLL,/* sk_busy_loop() owns this NAPI */NAPI_STATE_PREFER_BUSY_POLL,/* prefer busy-polling over softirq processing*/+NAPI_STATE_THREADED,/* The poll is performed inside its own thread*/};enum{
If you are reducing the function to just a prototype it might make
sense to move the doxygen comments to the definition of the function
rather than leaving them here. That way when you change the
functionality it is easier to update the comments as it is all in the
same place.
quoted hunk
/**
* napi_synchronize - wait until NAPI is not running
I would prefer to see this done like the wol_enabled as a bit field
or at least converted to a u8 instead of a bool. Last I knew we
weren't really supposed to use bool in structures since some
architectures will make it a 32b value.
@@ -1493,6 +1494,36 @@ void netdev_notify_peers(struct net_device *dev)}EXPORT_SYMBOL(netdev_notify_peers);+staticintnapi_threaded_poll(void*data);++staticintnapi_kthread_create(structnapi_struct*n)+{+interr=0;++/* Create and wake up the kthread once to put it in+*TASK_INTERRUPTIBLEmodetoavoidtheblockedtask+*warningandworkwithloadavg.+*/+n->thread=kthread_run(napi_threaded_poll,n,"napi/%s-%d",+n->dev->name,n->napi_id);+if(IS_ERR(n->thread)){+err=PTR_ERR(n->thread);+pr_err("kthread_run failed with err %d\n",err);+n->thread=NULL;+}++returnerr;+}++staticvoidnapi_kthread_stop(structnapi_struct*n)+{+if(!n->thread)+return;
You could probably flatten this bit by doing:
if (!threaded) {
clear_bit(NAPI_STATE_THREADED, &n->state);
return 0;
}
Then you could just pull the rest of this out of the if statement and
flatten it a bit.
I am not sure what the point is in having a return value if you are
just using it to trigger a WARN_ON. It might make more sense to
actually set the WARN_ON inside of napi_set_threaded instead of having
it here as you could then identify the error much more easily. Or for
that matter you might be able to use something like pr_warn which
would allow you a more detailed message about the specific netdev that
experienced the failure.
@@ -6866,6 +6934,51 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll) return work; }+static int napi_thread_wait(struct napi_struct *napi)+{+ set_current_state(TASK_INTERRUPTIBLE);++ while (!kthread_should_stop() && !napi_disable_pending(napi)) {+ if (test_bit(NAPI_STATE_SCHED, &napi->state)) {+ WARN_ON(!list_empty(&napi->poll_list));+ __set_current_state(TASK_RUNNING);+ return 0;+ }++ schedule();+ set_current_state(TASK_INTERRUPTIBLE);+ }+ __set_current_state(TASK_RUNNING);+ return -1;+}++static int napi_threaded_poll(void *data)+{+ struct napi_struct *napi = data;+ void *have;++ while (!napi_thread_wait(napi)) {+ for (;;) {+ bool repoll = false;++ local_bh_disable();++ have = netpoll_poll_lock(napi);+ __napi_poll(napi, &repoll);+ netpoll_poll_unlock(have);+
So it looks like v3 of this patch set was making use of the budget but
for v4 that went away and you had this. I was wondering why? One thing
that seems odd to me is that we are limiting the device to only
clearing one NAPI_POLL_WEIGHT of packets between flushing the freed
skbs and reenabling the bottom halves.
I'm wondering if it might make more sense to have a tunable like
netdev_budget that could be used for this to allow for more time
between flushes, bh enables, and cond_resched checks.
From: Alexander Duyck <hidden> Date: 2021-01-15 03:35:10
On Thu, Jan 14, 2021 at 4:34 PM Wei Wang [off-list ref] wrote:
quoted hunk
This patch adds a new sysfs attribute to the network device class.
Said attribute provides a per-device control to enable/disable the
threaded mode for all the napi instances of the given network device.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 28 +++++++++++++++++
net/core/net-sysfs.c | 63 +++++++++++++++++++++++++++++++++++++++
3 files changed, 93 insertions(+)
@@ -6754,6 +6754,34 @@ static int napi_set_threaded(struct napi_struct *n, bool threaded)returnerr;}+staticvoiddev_disable_threaded_all(structnet_device*dev)+{+structnapi_struct*napi;++list_for_each_entry(napi,&dev->napi_list,dev_list)+napi_set_threaded(napi,false);+}++intdev_set_threaded(structnet_device*dev,boolthreaded)+{+structnapi_struct*napi;+intret;++dev->threaded=threaded;+list_for_each_entry(napi,&dev->napi_list,dev_list){+ret=napi_set_threaded(napi,threaded);+if(ret){+/* Error occurred on one of the napi,+*resetthreadedmodeonallnapi.+*/+dev_disable_threaded_all(dev);+break;+}+}++returnret;
This doesn't seem right. The NAPI instances can be active while this
is occuring can they not? I would think at a minimum you need to go
through a napi_disable/napi_enable in order to toggle this value for
each NAPI instance. Otherwise aren't you at risk for racing and having
a napi_schedule attempt to wake up the thread before it has been
allocated?
quoted hunk
+}
+
void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
int (*poll)(struct napi_struct *, int), int weight)
{
@@ -538,6 +538,68 @@ static ssize_t phys_switch_id_show(struct device *dev,}staticDEVICE_ATTR_RO(phys_switch_id);+staticssize_tthreaded_show(structdevice*dev,+structdevice_attribute*attr,char*buf)+{+structnet_device*netdev=to_net_dev(dev);+structnapi_struct*n;+boolenabled;+intret;++if(!rtnl_trylock())+returnrestart_syscall();++if(!dev_isalive(netdev)){+ret=-EINVAL;+gotounlock;+}++if(list_empty(&netdev->napi_list)){+ret=-EOPNOTSUPP;+gotounlock;+}++/* Only return true if all napi have threaded mode.+*Theinconsistencycouldhappenwhenthedevicedrivercalls+*napi_disable()/napi_enable()withdev->threadedsettotrue,+*butnapi_kthread_create()fails.+*Wereturnfalseinthiscasetoremindtheuserthatoneor+*morenapididnothavethreadedmodeenabledproperly.+*/+list_for_each_entry(n,&netdev->napi_list,dev_list){+enabled=!!test_bit(NAPI_STATE_THREADED,&n->state);+if(!enabled)+break;+}+
This logic seems backwards to me. If we have it enabled for any of
them it seems like we should report it was enabled. Otherwise we are
going to be leaking out instances of threaded napi and not be able to
easily find where they are coming from. If nothing else it might make
sense to have this as a ternary value where it is either enabled,
disabled, or partial/broken.
Also why bother testing each queue when you already have dev->threaded?
I am not sure what the point is in having a return value if you are
just using it to trigger a WARN_ON. It might make more sense to
actually set the WARN_ON inside of napi_set_threaded instead of having
it here as you could then identify the error much more easily. Or for
that matter you might be able to use something like pr_warn which
would allow you a more detailed message about the specific netdev that
experienced the failure.
One additional change I would make here. The call to napi_set_threaded
should be moved to before the smp_mb__before_atomic(). That way we can
guarantee that the threaded flag and task_struct pointer are visible
to all consumers before they can set NAPI_STATE_SCHED. Otherwise I
think we run the risk of a race where a napi request could fire before
we have finished configuring it.
On Thu, Jan 14, 2021 at 7:34 PM Alexander Duyck
[off-list ref] wrote:
On Thu, Jan 14, 2021 at 4:34 PM Wei Wang [off-list ref] wrote:
quoted
This patch adds a new sysfs attribute to the network device class.
Said attribute provides a per-device control to enable/disable the
threaded mode for all the napi instances of the given network device.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 28 +++++++++++++++++
net/core/net-sysfs.c | 63 +++++++++++++++++++++++++++++++++++++++
3 files changed, 93 insertions(+)
@@ -6754,6 +6754,34 @@ static int napi_set_threaded(struct napi_struct *n, bool threaded)returnerr;}+staticvoiddev_disable_threaded_all(structnet_device*dev)+{+structnapi_struct*napi;++list_for_each_entry(napi,&dev->napi_list,dev_list)+napi_set_threaded(napi,false);+}++intdev_set_threaded(structnet_device*dev,boolthreaded)+{+structnapi_struct*napi;+intret;++dev->threaded=threaded;+list_for_each_entry(napi,&dev->napi_list,dev_list){+ret=napi_set_threaded(napi,threaded);+if(ret){+/* Error occurred on one of the napi,+*resetthreadedmodeonallnapi.+*/+dev_disable_threaded_all(dev);+break;+}+}++returnret;
This doesn't seem right. The NAPI instances can be active while this
is occuring can they not? I would think at a minimum you need to go
through a napi_disable/napi_enable in order to toggle this value for
each NAPI instance. Otherwise aren't you at risk for racing and having
a napi_schedule attempt to wake up the thread before it has been
allocated?
Yes. The napi instance could be active when this occurs. And I think
it is OK. It is cause napi_set_threaded() only sets
NAPI_STATE_THREADED bit after successfully created the kthread. And
___napi_schedule() only tries to wake up the kthread after testing the
THREADED bit.
quoted
+}
+
void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
int (*poll)(struct napi_struct *, int), int weight)
{
@@ -538,6 +538,68 @@ static ssize_t phys_switch_id_show(struct device *dev,}staticDEVICE_ATTR_RO(phys_switch_id);+staticssize_tthreaded_show(structdevice*dev,+structdevice_attribute*attr,char*buf)+{+structnet_device*netdev=to_net_dev(dev);+structnapi_struct*n;+boolenabled;+intret;++if(!rtnl_trylock())+returnrestart_syscall();++if(!dev_isalive(netdev)){+ret=-EINVAL;+gotounlock;+}++if(list_empty(&netdev->napi_list)){+ret=-EOPNOTSUPP;+gotounlock;+}++/* Only return true if all napi have threaded mode.+*Theinconsistencycouldhappenwhenthedevicedrivercalls+*napi_disable()/napi_enable()withdev->threadedsettotrue,+*butnapi_kthread_create()fails.+*Wereturnfalseinthiscasetoremindtheuserthatoneor+*morenapididnothavethreadedmodeenabledproperly.+*/+list_for_each_entry(n,&netdev->napi_list,dev_list){+enabled=!!test_bit(NAPI_STATE_THREADED,&n->state);+if(!enabled)+break;+}+
This logic seems backwards to me. If we have it enabled for any of
them it seems like we should report it was enabled. Otherwise we are
going to be leaking out instances of threaded napi and not be able to
easily find where they are coming from. If nothing else it might make
sense to have this as a ternary value where it is either enabled,
disabled, or partial/broken.
Good point. The reason to return true only if all napi have threaded
enabled, is I would like this return value to serve as a signal to the
user to indicate that the threaded mode is not enabled successfully
for all napi instances, when the user tries to enable it, but then got
"disabled".
But maybe using a ternary value is a better idea. I will see how to change that.
Also why bother testing each queue when you already have dev->threaded?
It is cause I use dev-> threaded to store what user wants to set the
threaded mode to. But if it is set partially or it is broken, I'd like
to return "disabled".
Again, I will see how to implement a ternary value.
From: Alexander Duyck <hidden> Date: 2021-01-15 23:08:56
On Fri, Jan 15, 2021 at 1:54 PM Wei Wang [off-list ref] wrote:
On Thu, Jan 14, 2021 at 7:34 PM Alexander Duyck
[off-list ref] wrote:
quoted
On Thu, Jan 14, 2021 at 4:34 PM Wei Wang [off-list ref] wrote:
quoted
This patch adds a new sysfs attribute to the network device class.
Said attribute provides a per-device control to enable/disable the
threaded mode for all the napi instances of the given network device.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 28 +++++++++++++++++
net/core/net-sysfs.c | 63 +++++++++++++++++++++++++++++++++++++++
3 files changed, 93 insertions(+)
@@ -6754,6 +6754,34 @@ static int napi_set_threaded(struct napi_struct *n, bool threaded)returnerr;}+staticvoiddev_disable_threaded_all(structnet_device*dev)+{+structnapi_struct*napi;++list_for_each_entry(napi,&dev->napi_list,dev_list)+napi_set_threaded(napi,false);+}++intdev_set_threaded(structnet_device*dev,boolthreaded)+{+structnapi_struct*napi;+intret;++dev->threaded=threaded;+list_for_each_entry(napi,&dev->napi_list,dev_list){+ret=napi_set_threaded(napi,threaded);+if(ret){+/* Error occurred on one of the napi,+*resetthreadedmodeonallnapi.+*/+dev_disable_threaded_all(dev);+break;+}+}++returnret;
This doesn't seem right. The NAPI instances can be active while this
is occuring can they not? I would think at a minimum you need to go
through a napi_disable/napi_enable in order to toggle this value for
each NAPI instance. Otherwise aren't you at risk for racing and having
a napi_schedule attempt to wake up the thread before it has been
allocated?
Yes. The napi instance could be active when this occurs. And I think
it is OK. It is cause napi_set_threaded() only sets
NAPI_STATE_THREADED bit after successfully created the kthread. And
___napi_schedule() only tries to wake up the kthread after testing the
THREADED bit.
But what do you have guaranteeing that the kthread has been written to
memory? That is what I was getting at. Just because you have written
the value doesn't mean it is in memory yet so you would probably need
an smb_mb__before_atomic() barrier call before you set the bit.
Also I am not sure it is entirely safe to have the instance polling
while you are doing this. That is why I am thinking if the instance is
enabled then a napi_disable/napi_enable would be preferable.
On Fri, Jan 15, 2021 at 3:08 PM Alexander Duyck
[off-list ref] wrote:
On Fri, Jan 15, 2021 at 1:54 PM Wei Wang [off-list ref] wrote:
quoted
On Thu, Jan 14, 2021 at 7:34 PM Alexander Duyck
[off-list ref] wrote:
quoted
On Thu, Jan 14, 2021 at 4:34 PM Wei Wang [off-list ref] wrote:
quoted
This patch adds a new sysfs attribute to the network device class.
Said attribute provides a per-device control to enable/disable the
threaded mode for all the napi instances of the given network device.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 28 +++++++++++++++++
net/core/net-sysfs.c | 63 +++++++++++++++++++++++++++++++++++++++
3 files changed, 93 insertions(+)
@@ -6754,6 +6754,34 @@ static int napi_set_threaded(struct napi_struct *n, bool threaded)returnerr;}+staticvoiddev_disable_threaded_all(structnet_device*dev)+{+structnapi_struct*napi;++list_for_each_entry(napi,&dev->napi_list,dev_list)+napi_set_threaded(napi,false);+}++intdev_set_threaded(structnet_device*dev,boolthreaded)+{+structnapi_struct*napi;+intret;++dev->threaded=threaded;+list_for_each_entry(napi,&dev->napi_list,dev_list){+ret=napi_set_threaded(napi,threaded);+if(ret){+/* Error occurred on one of the napi,+*resetthreadedmodeonallnapi.+*/+dev_disable_threaded_all(dev);+break;+}+}++returnret;
This doesn't seem right. The NAPI instances can be active while this
is occuring can they not? I would think at a minimum you need to go
through a napi_disable/napi_enable in order to toggle this value for
each NAPI instance. Otherwise aren't you at risk for racing and having
a napi_schedule attempt to wake up the thread before it has been
allocated?
Yes. The napi instance could be active when this occurs. And I think
it is OK. It is cause napi_set_threaded() only sets
NAPI_STATE_THREADED bit after successfully created the kthread. And
___napi_schedule() only tries to wake up the kthread after testing the
THREADED bit.
But what do you have guaranteeing that the kthread has been written to
memory? That is what I was getting at. Just because you have written
the value doesn't mean it is in memory yet so you would probably need
an smb_mb__before_atomic() barrier call before you set the bit.
Noted. Will look into this.
Also I am not sure it is entirely safe to have the instance polling
while you are doing this. That is why I am thinking if the instance is
enabled then a napi_disable/napi_enable would be preferable.
When the napi is actively being polled in threaded mode, we will keep
rescheduling the kthread and calling __napi_poll() until
NAPI_SCHED_STATE is cleared by napi_complete_done(). And during the
next time napi_schedule() is called, we re-evaluate
NAPI_STATE_THREADED bit to see if we should wake up kthread, or
generate softirq.
And for the other way around, if napi is being handled during
net_rx_action(), toggling the bit won't cause immediate wake-up of the
kthread, but will wait for NAPI_SCHED_STATE to be cleared, and the
next time napi_schedule() is called.
I think it is OK. WDYT?
From: Alexander Duyck <hidden> Date: 2021-01-16 02:20:32
On Fri, Jan 15, 2021 at 4:44 PM Wei Wang [off-list ref] wrote:
On Fri, Jan 15, 2021 at 3:08 PM Alexander Duyck
[off-list ref] wrote:
quoted
On Fri, Jan 15, 2021 at 1:54 PM Wei Wang [off-list ref] wrote:
quoted
On Thu, Jan 14, 2021 at 7:34 PM Alexander Duyck
[off-list ref] wrote:
quoted
On Thu, Jan 14, 2021 at 4:34 PM Wei Wang [off-list ref] wrote:
quoted
This patch adds a new sysfs attribute to the network device class.
Said attribute provides a per-device control to enable/disable the
threaded mode for all the napi instances of the given network device.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 28 +++++++++++++++++
net/core/net-sysfs.c | 63 +++++++++++++++++++++++++++++++++++++++
3 files changed, 93 insertions(+)
@@ -6754,6 +6754,34 @@ static int napi_set_threaded(struct napi_struct *n, bool threaded)returnerr;}+staticvoiddev_disable_threaded_all(structnet_device*dev)+{+structnapi_struct*napi;++list_for_each_entry(napi,&dev->napi_list,dev_list)+napi_set_threaded(napi,false);+}++intdev_set_threaded(structnet_device*dev,boolthreaded)+{+structnapi_struct*napi;+intret;++dev->threaded=threaded;+list_for_each_entry(napi,&dev->napi_list,dev_list){+ret=napi_set_threaded(napi,threaded);+if(ret){+/* Error occurred on one of the napi,+*resetthreadedmodeonallnapi.+*/+dev_disable_threaded_all(dev);+break;+}+}++returnret;
This doesn't seem right. The NAPI instances can be active while this
is occuring can they not? I would think at a minimum you need to go
through a napi_disable/napi_enable in order to toggle this value for
each NAPI instance. Otherwise aren't you at risk for racing and having
a napi_schedule attempt to wake up the thread before it has been
allocated?
Yes. The napi instance could be active when this occurs. And I think
it is OK. It is cause napi_set_threaded() only sets
NAPI_STATE_THREADED bit after successfully created the kthread. And
___napi_schedule() only tries to wake up the kthread after testing the
THREADED bit.
But what do you have guaranteeing that the kthread has been written to
memory? That is what I was getting at. Just because you have written
the value doesn't mean it is in memory yet so you would probably need
an smb_mb__before_atomic() barrier call before you set the bit.
Noted. Will look into this.
quoted
Also I am not sure it is entirely safe to have the instance polling
while you are doing this. That is why I am thinking if the instance is
enabled then a napi_disable/napi_enable would be preferable.
When the napi is actively being polled in threaded mode, we will keep
rescheduling the kthread and calling __napi_poll() until
NAPI_SCHED_STATE is cleared by napi_complete_done(). And during the
next time napi_schedule() is called, we re-evaluate
NAPI_STATE_THREADED bit to see if we should wake up kthread, or
generate softirq.
And for the other way around, if napi is being handled during
net_rx_action(), toggling the bit won't cause immediate wake-up of the
kthread, but will wait for NAPI_SCHED_STATE to be cleared, and the
next time napi_schedule() is called.
I think it is OK. WDYT?
It is hard to say. The one spot that gives me a bit of concern is the
NAPIF_STATE_MISSED case in napi_complete_done. It is essentially would
become a switchover point between the two while we are actively
polling inside the driver. You end up with NAPI_SCHED_STATE not being
toggled but jumping from one to the other.
On Fri, Jan 15, 2021 at 6:18 PM Alexander Duyck
[off-list ref] wrote:
On Fri, Jan 15, 2021 at 4:44 PM Wei Wang [off-list ref] wrote:
quoted
On Fri, Jan 15, 2021 at 3:08 PM Alexander Duyck
[off-list ref] wrote:
quoted
On Fri, Jan 15, 2021 at 1:54 PM Wei Wang [off-list ref] wrote:
quoted
On Thu, Jan 14, 2021 at 7:34 PM Alexander Duyck
[off-list ref] wrote:
quoted
On Thu, Jan 14, 2021 at 4:34 PM Wei Wang [off-list ref] wrote:
quoted
This patch adds a new sysfs attribute to the network device class.
Said attribute provides a per-device control to enable/disable the
threaded mode for all the napi instances of the given network device.
Co-developed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Co-developed-by: Hannes Frederic Sowa <redacted>
Signed-off-by: Hannes Frederic Sowa <redacted>
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Wei Wang <redacted>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 28 +++++++++++++++++
net/core/net-sysfs.c | 63 +++++++++++++++++++++++++++++++++++++++
3 files changed, 93 insertions(+)
@@ -6754,6 +6754,34 @@ static int napi_set_threaded(struct napi_struct *n, bool threaded)returnerr;}+staticvoiddev_disable_threaded_all(structnet_device*dev)+{+structnapi_struct*napi;++list_for_each_entry(napi,&dev->napi_list,dev_list)+napi_set_threaded(napi,false);+}++intdev_set_threaded(structnet_device*dev,boolthreaded)+{+structnapi_struct*napi;+intret;++dev->threaded=threaded;+list_for_each_entry(napi,&dev->napi_list,dev_list){+ret=napi_set_threaded(napi,threaded);+if(ret){+/* Error occurred on one of the napi,+*resetthreadedmodeonallnapi.+*/+dev_disable_threaded_all(dev);+break;+}+}++returnret;
This doesn't seem right. The NAPI instances can be active while this
is occuring can they not? I would think at a minimum you need to go
through a napi_disable/napi_enable in order to toggle this value for
each NAPI instance. Otherwise aren't you at risk for racing and having
a napi_schedule attempt to wake up the thread before it has been
allocated?
Yes. The napi instance could be active when this occurs. And I think
it is OK. It is cause napi_set_threaded() only sets
NAPI_STATE_THREADED bit after successfully created the kthread. And
___napi_schedule() only tries to wake up the kthread after testing the
THREADED bit.
But what do you have guaranteeing that the kthread has been written to
memory? That is what I was getting at. Just because you have written
the value doesn't mean it is in memory yet so you would probably need
an smb_mb__before_atomic() barrier call before you set the bit.
Noted. Will look into this.
quoted
Also I am not sure it is entirely safe to have the instance polling
while you are doing this. That is why I am thinking if the instance is
enabled then a napi_disable/napi_enable would be preferable.
When the napi is actively being polled in threaded mode, we will keep
rescheduling the kthread and calling __napi_poll() until
NAPI_SCHED_STATE is cleared by napi_complete_done(). And during the
next time napi_schedule() is called, we re-evaluate
NAPI_STATE_THREADED bit to see if we should wake up kthread, or
generate softirq.
And for the other way around, if napi is being handled during
net_rx_action(), toggling the bit won't cause immediate wake-up of the
kthread, but will wait for NAPI_SCHED_STATE to be cleared, and the
next time napi_schedule() is called.
I think it is OK. WDYT?
It is hard to say. The one spot that gives me a bit of concern is the
NAPIF_STATE_MISSED case in napi_complete_done. It is essentially would
become a switchover point between the two while we are actively
polling inside the driver. You end up with NAPI_SCHED_STATE not being
toggled but jumping from one to the other.
Hmm.. Right. That is the one case where NAPI_SCHED_STATE will not be
toggled, but could potentially change the processing mode.
But still, I don't see any race in this case. The napi instance will
still either be processed in softirq mode by net_rx_action(), or in
the kthread mode, after napi_complete_done() calls __napi_schedule().