From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:19:51
Hi,
I thought I should go ahead and send this series out for comments.
Here I allow qdiscs to be run without taking the qdisc lock. As a
result statistics, gso skb, tx bad skb and a few other things need
to be "safe" to run without locks. It _should_ all be covered here.
Although I just noticed I must be missing a dec on the backlog
counter somewhere as one of my tests just ended with 0packets but
a nonzero bytes counter.
Also of note in this series I used the skb_array implementation
already in net-next for the tun/tap devices. With this implementation
for cases where lots of threads are hitting the same qdisc I see
a modest improvement but for cases like mq with pktgen where
everything is lined up nicely I see a fairly unpleasant regression.
I have a few thoughts on how to resolve this. First if we support
bulk_dequeue as an operation on the skb_array this should help
vs getting the consumer lock repeatedly. Also we really don't need
the HARD_TX_LOCK if we have a core per queue and XPS setup like many
multiqueue nics default to. And I need to go back and look at the
original alf ring implementation as well to see how it compares I
don't recall seeing the mq regression there.
Also after the above it might be nice to make all qdiscs support
the per cpu statistics and drop non per cpu cases just to simplify
the code and all the if/else branching where its not needed.
As usual any thoughts, comments, etc are welcome.
And I wasn't going to add these numbers just because they come from
an untuned system but why not.
Here are some initial numbers from pktgen on my development which
is a reasonable system (E5-2695) but I didn't do any work to tweak
the config so there is still a bunch of debug/hacking options still
running.
The pktgen command is
./samples/pktgen/pktgen_bench_xmit_mode_queue_xmit.sh -i eth3 -t X -s 64
pfifo_fast
original pps lockless diff
1 1418168 1269450 -148718
2 1587390 1553408 -33982
4 1084961 1683639 +598678
8 989636 1522723 +533087
12 1014018 1348172 +334154
mq
original pps lockless diff
1 1442018 1205180 -236838
2 2646069 2266095 -379974
4 5136200 4269470 -866730
8
12 13275671 10810909 -2464762
---
John Fastabend (10):
net: sched: allow qdiscs to handle locking
net: sched: qdisc_qlen for per cpu logic
net: sched: provide per cpu qstat helpers
net: sched: a dflt qdisc may be used with per cpu stats
net: sched: per cpu gso handlers
net: sched: support qdisc_reset on NOLOCK qdisc
net: sched: support skb_bad_tx with lockless qdisc
net: sched: pfifo_fast use alf_queue
net: sched: helper to sum qlen
net: sched: add support for TCQ_F_NOLOCK subqueues to sch_mq
include/net/gen_stats.h | 3
include/net/sch_generic.h | 105 ++++++++++++
net/core/dev.c | 32 +++-
net/core/gen_stats.c | 9 +
net/sched/sch_api.c | 12 +
net/sched/sch_generic.c | 385 +++++++++++++++++++++++++++++++++++----------
net/sched/sch_mq.c | 25 ++-
7 files changed, 467 insertions(+), 104 deletions(-)
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:20:15
This patch adds a flag for queueing disciplines to indicate the stack
does not need to use the qdisc lock to protect operations. This can
be used to build lockless scheduling algorithms and improving
performance.
The flag is checked in the tx path and the qdisc lock is only taken
if it is not set. For now use a conditional if statement. Later we
could be more aggressive if it proves worthwhile and use a static key
or wrap this in a likely().
Signed-off-by: John Fastabend <redacted>
---
include/net/sch_generic.h | 1 +
net/core/dev.c | 32 ++++++++++++++++++++++++++++----
net/sched/sch_generic.c | 24 ++++++++++++++++--------
3 files changed, 45 insertions(+), 12 deletions(-)
@@ -3896,19 +3917,22 @@ static void net_tx_action(struct softirq_action *h)while(head){structQdisc*q=head;-spinlock_t*root_lock;+spinlock_t*root_lock=NULL;head=head->next_sched;-root_lock=qdisc_lock(q);-spin_lock(root_lock);+if(!(q->flags&TCQ_F_NOLOCK)){+root_lock=qdisc_lock(q);+spin_lock(root_lock);+}/* We need to make sure head->next_sched is read*beforeclearing__QDISC_STATE_SCHED*/smp_mb__before_atomic();clear_bit(__QDISC_STATE_SCHED,&q->state);qdisc_run(q);-spin_unlock(root_lock);+if(!(q->flags&TCQ_F_NOLOCK))+spin_unlock(root_lock);}}}
@@ -170,7 +170,8 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,intret=NETDEV_TX_BUSY;/* And release qdisc */-spin_unlock(root_lock);+if(!(q->flags&TCQ_F_NOLOCK))+spin_unlock(root_lock);/* Note that we validate skb (GSO, checksum, ...) outside of locks */if(validate)
@@ -183,10 +184,13 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,HARD_TX_UNLOCK(dev,txq);}else{-spin_lock(root_lock);+if(!(q->flags&TCQ_F_NOLOCK))+spin_lock(root_lock);returnqdisc_qlen(q);}-spin_lock(root_lock);++if(!(q->flags&TCQ_F_NOLOCK))+spin_lock(root_lock);if(dev_xmit_complete(ret)){/* Driver sent out skb successfully or skb was consumed */
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:20:43
This is a bit interesting because it means sch_direct_xmit will
return a positive value which causes the dequeue/xmit cycle to
continue only when a specific cpu has a qlen > 0.
However checking each cpu for qlen will break performance so
its important to note that qdiscs that set the no lock bit need
to have some sort of per cpu enqueue/dequeue data structure that
maps to the per cpu qlen value.
Signed-off-by: John Fastabend <redacted>
---
include/net/sch_generic.h | 8 ++++++++
1 file changed, 8 insertions(+)
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:21:12
The per cpu qstats support was added with per cpu bstat support which
is currently used by the ingress qdisc. This patch adds a set of
helpers needed to make other qdiscs that use qstats per cpu as well.
Signed-off-by: John Fastabend <redacted>
---
include/net/sch_generic.h | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:21:41
Enable dflt qdisc support for per cpu stats before this patch a
dflt qdisc was required to use the global statistics qstats and
bstats.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
@@ -647,18 +647,34 @@ struct Qdisc *qdisc_create_dflt(struct netdev_queue *dev_queue,structQdisc*sch;if(!try_module_get(ops->owner))-gotoerrout;+returnNULL;sch=qdisc_alloc(dev_queue,ops);if(IS_ERR(sch))-gotoerrout;+returnNULL;sch->parent=parentid;-if(!ops->init||ops->init(sch,NULL)==0)+if(!ops->init)returnsch;-qdisc_destroy(sch);+if(ops->init(sch,NULL))+gotoerrout;++/* init() may have set percpu flags so init data structures */+if(qdisc_is_percpu_stats(sch)){+sch->cpu_bstats=+netdev_alloc_pcpu_stats(structgnet_stats_basic_cpu);+if(!sch->cpu_bstats)+gotoerrout;++sch->cpu_qstats=alloc_percpu(structgnet_stats_queue);+if(!sch->cpu_qstats)+gotoerrout;+}++returnsch;errout:+qdisc_destroy(sch);returnNULL;}EXPORT_SYMBOL(qdisc_create_dflt);
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:22:10
The net sched infrastructure has a gso ptr that points to skb structs
that have failed to be enqueued by the device driver.
This can happen when multiple cores try to push a skb onto the same
underlying hardware queue resulting in lock contention. This case is
handled by a cpu collision handler handle_dev_cpu_collision(). Another
case occurs when the stack overruns the drivers low level tx queues
capacity. Ideally these should be a rare occurrence in a well-tuned
system but they do happen.
To handle this in the lockless case use a per cpu gso field to park
the skb until the conflict can be resolved. Note at this point the
skb has already been popped off the qdisc so it has to be handled
by the infrastructure.
Signed-off-by: John Fastabend <redacted>
---
include/net/sch_generic.h | 37 +++++++++++++++++++++++
net/sched/sch_api.c | 7 ++++
net/sched/sch_generic.c | 71 ++++++++++++++++++++++++++++++++++++++++++---
3 files changed, 110 insertions(+), 5 deletions(-)
@@ -725,6 +731,22 @@ static inline struct sk_buff *qdisc_peek_dequeued(struct Qdisc *sch)returnsch->gso_skb;}+staticinlinestructsk_buff*qdisc_peek_dequeued_cpu(structQdisc*sch)+{+structgso_cell*gso=this_cpu_ptr(sch->gso_cpu_skb);++if(!gso->skb){+structsk_buff*skb=sch->dequeue(sch);++if(skb){+gso->skb=skb;+qdisc_qstats_cpu_qlen_inc(sch);+}+}++returngso->skb;+}+/* use instead of qdisc->dequeue() for all qdiscs queried with ->peek() */staticinlinestructsk_buff*qdisc_dequeue_peeked(structQdisc*sch){
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:22:37
The qdisc_reset operation depends on the qdisc lock at the moment
to halt any additions to gso_skb and statistics while the list is
free'd and the stats zeroed.
Without the qdisc lock we can not guarantee another cpu is not in
the process of adding a skb to one of the "cells". Here are the
two cases we have to handle.
case 1: qdisc_graft operation. In this case a "new" qdisc is attached
and the 'qdisc_destroy' operation is called on the old qdisc.
The destroy operation will wait a rcu grace period and call
qdisc_rcu_free(). At which point gso_cpu_skb is free'd along
with all stats so no need to zero stats and gso_cpu_skb from
the reset operation itself.
Because we can not continue to call qdisc_reset before waiting
an rcu grace period so that the qdisc is detached from all
cpus simply do not call qdisc_reset() at all and let the
qdisc_destroy operation clean up the qdisc. Note, a refcnt
greater than 1 would cause the destroy operation to be
aborted however if this ever happened the reference to the
qdisc would be lost and we would have a memory leak.
case 2: dev_deactivate sequence. This can come from a user bringing
the interface down which causes the gso_skb list to be flushed
and the qlen zero'd. At the moment this is protected by the
qdisc lock so while we clear the qlen/gso_skb fields we are
guaranteed no new skbs are added. For the lockless case
though this is not true. To resolve this move the qdisc_reset
call after the new qdisc is assigned and a grace period is
exercised to ensure no new skbs can be enqueued. Further
the RTNL lock is held so we can not get another call to
activate the qdisc while the skb lists are being free'd.
Finally, fix qdisc_reset to handle the per cpu stats and
skb lists.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 45 +++++++++++++++++++++++++++++++++++----------
1 file changed, 35 insertions(+), 10 deletions(-)
@@ -814,10 +828,6 @@ struct Qdisc *dev_graft_qdisc(struct netdev_queue *dev_queue,root_lock=qdisc_lock(oqdisc);spin_lock_bh(root_lock);-/* Prune old scheduler */-if(oqdisc&&atomic_read(&oqdisc->refcnt)<=1)-qdisc_reset(oqdisc);-/* ... and graft new one */if(qdisc==NULL)qdisc=&noop_qdisc;
@@ -988,20 +1006,27 @@ void dev_deactivate_many(struct list_head *head)&noop_qdisc);dev_watchdog_down(dev);-sync_needed|=!dev->dismantle;}/* Wait for outstanding qdisc-less dev_queue_xmit calls.*Thisisavoidedifalldevicesareindismantlephase:*Callerwillcallsynchronize_net()forus*/-if(sync_needed)-synchronize_net();+synchronize_net();/* Wait for outstanding qdisc_run calls. */-list_for_each_entry(dev,head,close_list)+list_for_each_entry(dev,head,close_list){while(some_qdisc_is_busy(dev))yield();++/* The new qdisc is assigned at this point so we can safely+*unwindstaleskblistsandqdiscstatistics+*/+netdev_for_each_tx_queue(dev,dev_qdisc_reset,NULL);+if(dev_ingress_queue(dev))+dev_qdisc_reset(dev,dev_ingress_queue(dev),NULL);+}+}voiddev_deactivate(structnet_device*dev)
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:23:06
Similar to how gso is handled skb_bad_tx needs to be per cpu to handle
lockless qdisc with multiple writer/producers.
Signed-off-by: John Fastabend <redacted>
---
include/net/sch_generic.h | 7 +++
net/sched/sch_api.c | 5 ++
net/sched/sch_generic.c | 94 +++++++++++++++++++++++++++++++++++++++++----
3 files changed, 97 insertions(+), 9 deletions(-)
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:23:33
This converts the pfifo_fast qdisc to use the alf_queue enqueue and
dequeue routines then sets the NOLOCK bit.
This also removes the logic used to pick the next band to dequeue from
and instead just checks each alf_queue for packets from top priority
to lowest. This might need to be a bit more clever but seems to work
for now.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 131 +++++++++++++++++++++++++++--------------------
1 file changed, 75 insertions(+), 56 deletions(-)
@@ -654,24 +646,51 @@ nla_put_failure:staticintpfifo_fast_init(structQdisc*qdisc,structnlattr*opt){-intprio;+unsignedintqlen=qdisc_dev(qdisc)->tx_queue_len;structpfifo_fast_priv*priv=qdisc_priv(qdisc);+intprio;++/* guard against zero length rings */+if(!qlen)+return-EINVAL;++for(prio=0;prio<PFIFO_FAST_BANDS;prio++){+structskb_array*q=band2list(priv,prio);+interr;-for(prio=0;prio<PFIFO_FAST_BANDS;prio++)-__skb_queue_head_init(band2list(priv,prio));+err=skb_array_init(q,qlen,GFP_KERNEL);+if(err)+return-ENOMEM;+}/* Can by-pass the queue discipline */qdisc->flags|=TCQ_F_CAN_BYPASS;+qdisc->flags|=TCQ_F_NOLOCK;+qdisc->flags|=TCQ_F_CPUSTATS;+return0;}+staticvoidpfifo_fast_destroy(structQdisc*sch)+{+structpfifo_fast_priv*priv=qdisc_priv(sch);+intprio;++for(prio=0;prio<PFIFO_FAST_BANDS;prio++){+structskb_array*q=band2list(priv,prio);++skb_array_cleanup(q);+}+}+structQdisc_opspfifo_fast_ops__read_mostly={.id="pfifo_fast",.priv_size=sizeof(structpfifo_fast_priv),.enqueue=pfifo_fast_enqueue,.dequeue=pfifo_fast_dequeue,-.peek=pfifo_fast_peek,+.peek=qdisc_peek_dequeued,.init=pfifo_fast_init,+.destroy=pfifo_fast_destroy,.reset=pfifo_fast_reset,.dump=pfifo_fast_dump,.owner=THIS_MODULE,
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:23:54
Reporting qlen when qlen is per cpu requires aggregating the per
cpu counters. This adds a helper routine for this.
Signed-off-by: John Fastabend <redacted>
---
include/net/sch_generic.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:24:15
The sch_mq qdisc creates a sub-qdisc per tx queue which are then
called independently for enqueue and dequeue operations. However
statistics are aggregated and pushed up to the "master" qdisc.
This patch adds support for any of the sub-qdiscs to be per cpu
statistic qdiscs. To handle this case add a check when calculating
stats and aggregate the per cpu stats if needed.
Also exports __gnet_stats_copy_queue() to use as a helper function.
Signed-off-by: John Fastabend <redacted>
---
include/net/gen_stats.h | 3 +++
net/core/gen_stats.c | 9 +++++----
net/sched/sch_mq.c | 25 ++++++++++++++++++-------
3 files changed, 26 insertions(+), 11 deletions(-)
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-14 06:45:09
On 16-07-13 11:19 PM, John Fastabend wrote:
This patch adds a flag for queueing disciplines to indicate the stack
does not need to use the qdisc lock to protect operations. This can
be used to build lockless scheduling algorithms and improving
performance.
The flag is checked in the tx path and the qdisc lock is only taken
if it is not set. For now use a conditional if statement. Later we
could be more aggressive if it proves worthwhile and use a static key
or wrap this in a likely().
Signed-off-by: John Fastabend <redacted>
---
[...]
quoted hunk
@@ -3075,6 +3075,27 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q, int rc; qdisc_calculate_pkt_len(skb, q);++ if (q->flags & TCQ_F_NOLOCK) {+ if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {+ __qdisc_drop(skb, &to_free);+ rc = NET_XMIT_DROP;+ } else if ((q->flags & TCQ_F_CAN_BYPASS) && !qdisc_qlen(q)) {+ qdisc_bstats_cpu_update(q, skb);+ __qdisc_run(q);
Reviewing these patches now and noticed this qdisc_run() is not
needed.
On Wed, 13 Jul 2016 23:23:12 -0700
John Fastabend [off-list ref] wrote:
This converts the pfifo_fast qdisc to use the alf_queue enqueue and
dequeue routines then sets the NOLOCK bit.
Should have said skb_array, not alf_queue ;-)
> This also removes the logic used to pick the next band to dequeue from
quoted hunk
and instead just checks each alf_queue for packets from top priority
to lowest. This might need to be a bit more clever but seems to work
for now.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 131 +++++++++++++++++++++++++++--------------------
1 file changed, 75 insertions(+), 56 deletions(-)
On Wed, Jul 13, 2016 at 11:23:12PM -0700, John Fastabend wrote:
This converts the pfifo_fast qdisc to use the alf_queue enqueue and
dequeue routines then sets the NOLOCK bit.
This also removes the logic used to pick the next band to dequeue from
and instead just checks each alf_queue for packets from top priority
to lowest. This might need to be a bit more clever but seems to work
for now.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 131 +++++++++++++++++++++++++++--------------------
For this particular qdisc the performance gain should come from
granularityof spin_lock, right?
Before we were taking the lock much earlier. Here we keep the lock,
but for the very short time.
original pps lockless diff
1 1418168 1269450 -148718
2 1587390 1553408 -33982
4 1084961 1683639 +598678
8 989636 1522723 +533087
12 1014018 1348172 +334154
so perf for 1 cpu case is mainly due to array vs list,
since number of locks is still the same and there is no collision ?
but then why shorter lock give higher overhead in multi cpu cases?
That would have been the main target for performance improvement?
Looks like mq gets the most benefit, because it's lockless internally
which makes sense.
In general I think this is the right direction where tc infra should move to.
I'm only not sure whether it's worth converting pfifo to skb_array.
Probably alf queue would have been a better alternative.
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-15 00:07:45
On 16-07-14 04:42 PM, Alexei Starovoitov wrote:
On Wed, Jul 13, 2016 at 11:23:12PM -0700, John Fastabend wrote:
quoted
This converts the pfifo_fast qdisc to use the alf_queue enqueue and
dequeue routines then sets the NOLOCK bit.
This also removes the logic used to pick the next band to dequeue from
and instead just checks each alf_queue for packets from top priority
to lowest. This might need to be a bit more clever but seems to work
for now.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 131 +++++++++++++++++++++++++++--------------------
For this particular qdisc the performance gain should come from
granularityof spin_lock, right?
And the fact that the consumer and producer are using different
locks now.
Before we were taking the lock much earlier. Here we keep the lock,
but for the very short time.
original pps lockless diff
1 1418168 1269450 -148718
2 1587390 1553408 -33982
4 1084961 1683639 +598678
8 989636 1522723 +533087
12 1014018 1348172 +334154
so perf for 1 cpu case is mainly due to array vs list,
since number of locks is still the same and there is no collision ?
but then why shorter lock give higher overhead in multi cpu cases?
So in this case running pfifo_fast as the root qdisc with 12 threads
means we have 12 producers hitting a single enqueue() path where as with
mq and only looking at pktgen numbers we have one thread for each
skb_array.
That would have been the main target for performance improvement?
Maybe I should fire up a TCP test with 1000's of threads to see what
the perf numbers look like.
Looks like mq gets the most benefit, because it's lockless internally
which makes sense.
In general I think this is the right direction where tc infra should move to.
I'm only not sure whether it's worth converting pfifo to skb_array.
Probably alf queue would have been a better alternative.
Tomorrows task is to resurrect the alf_queue and look at its numbers
compared to this. Today was spent trying to remove the HARD_TX_LOCK
that protects the driver, in the mq case it seems this is not really
needed either.
.John
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-15 00:09:56
On 16-07-14 08:11 AM, Jesper Dangaard Brouer wrote:
On Wed, 13 Jul 2016 23:23:12 -0700
John Fastabend [off-list ref] wrote:
quoted
This converts the pfifo_fast qdisc to use the alf_queue enqueue and
dequeue routines then sets the NOLOCK bit.
Should have said skb_array, not alf_queue ;-)
I think I'll get numbers for the alf_queue to so we can compare them
as well. On the todo list for tomorrow.
> This also removes the logic used to pick the next band to dequeue from
quoted
and instead just checks each alf_queue for packets from top priority
to lowest. This might need to be a bit more clever but seems to work
for now.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 131 +++++++++++++++++++++++++++--------------------
1 file changed, 75 insertions(+), 56 deletions(-)
Do you need the _bh variant here? (Doesn't the qdisc run with BH disabled?)
Yep its inside rcu_read_lock_bh().
The call rcu_read_lock_bh() already disabled BH (local_bh_disable()).
Thus, you can use the normal variants of skb_array_produce(), it is
(approx 20 cycles) faster than the _bh variant...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
On Thu, 14 Jul 2016 17:07:33 -0700
John Fastabend [off-list ref] wrote:
On 16-07-14 04:42 PM, Alexei Starovoitov wrote:
quoted
On Wed, Jul 13, 2016 at 11:23:12PM -0700, John Fastabend wrote:
quoted
This converts the pfifo_fast qdisc to use the alf_queue enqueue and
dequeue routines then sets the NOLOCK bit.
This also removes the logic used to pick the next band to dequeue from
and instead just checks each alf_queue for packets from top priority
to lowest. This might need to be a bit more clever but seems to work
for now.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 131 +++++++++++++++++++++++++++--------------------
For this particular qdisc the performance gain should come from
granularityof spin_lock, right?
And the fact that the consumer and producer are using different
locks now.
Yes. Splitting up enqueue'ers (producer's) from the dequeuer (consumer)
is an important step, because today the qdisc layer have this problem
that enqueue'ers can starve the single dequeuer. The current
mitigation tricks are the enq busy_lock and bulk dequeue.
As John says, using skb_array cause producers and consumer to use
different locks.
quoted
Before we were taking the lock much earlier. Here we keep the lock,
but for the very short time.
original pps lockless diff
1 1418168 1269450 -148718
2 1587390 1553408 -33982
4 1084961 1683639 +598678
8 989636 1522723 +533087
12 1014018 1348172 +334154
It looks problematic that lockless is slower in the base single CPU
case, orig (1418168 pps) to lockless (1269450). By approx
(1/1418168-1/1269450)*10^9 = -82.60 ns. That base "regression" look
too high to start with.
How I view the results:
Negative scaling starts early for "original", which is the main problem
that we are looking to solve. The lockless does not show as much
scaling effect as expected, and start to show a trend towards negative
scaling.
quoted
so perf for 1 cpu case is mainly due to array vs list,
since number of locks is still the same and there is no collision ?
but then why shorter lock give higher overhead in multi cpu cases?
So in this case running pfifo_fast as the root qdisc with 12 threads
means we have 12 producers hitting a single enqueue() path where as with
mq and only looking at pktgen numbers we have one thread for each
skb_array.
The skb_array allow multi producer multi consumer (MPMC), but is
optimized towards the case of a single producer and a single consumer
(SPSC). The SPSC queue is usually implemented with much less
synchronization, but then you need some other guarantee that only a
single producer/consumer can be running.
quoted
That would have been the main target for performance improvement?
Maybe I should fire up a TCP test with 1000's of threads to see what
the perf numbers look like.
quoted
Looks like mq gets the most benefit, because it's lockless internally
which makes sense.
In general I think this is the right direction where tc infra should move to.
I'm only not sure whether it's worth converting pfifo to skb_array.
Probably alf queue would have been a better alternative.
Tomorrows task is to resurrect the alf_queue and look at its numbers
compared to this. Today was spent trying to remove the HARD_TX_LOCK
that protects the driver, in the mq case it seems this is not really
needed either.
I would be very interested in the alf_queue numbers. As alf_queue
should perform better with multiple producers. If you kept the single
TC dequeue'er rule, then you could use the MPSC variant of alf_queue.
My benchmarks from 2014 are avail in this presentation:
http://people.netfilter.org/hawk/presentations/nfws2014/dp-accel-qdisc-lockless.pdf
Also showing the mitigation effect of bulk-dequeue patches slide 12
(But I would like to see some new benchmarks for alf_queue slide 14)
But do notice, alf_queue have a design problem that skb_array solved.
Alf_queue have the problem of read-bouncing the remote/opposite CPUs
cache line, because it need to (1) at enqueue (producer) look if there
is free space (reading consumer.tail), and (2) at dequeue (consumer) if
any object are avail (reading producer.tail).
The alf_queue mitigate this by design problem by allowing doing bulk
enqueue and bulk dequeue. But I guess, you will not use that "mode", I
think I did in my NFWS2014 benchmarks.
The skb_array solved this design problem, by using the content of the
queue objects as a maker for free/full condition. The alf_queue cannot
do so easily, because of it's bulk design, that need to reserve part of
the queue. Thus, we likely need some new queue design, which is a
hybrid between alf_queue and skb_array, for this use-case.
I actually wrote some queue micro-benchmarks that show the strength and
weaknesses of both skb_array[1] and alf_queue[2].
[1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/skb_array_parallel01.c
[2] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/alf_queue_parallel01.c
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
Do you need the _bh variant here? (Doesn't the qdisc run with BH disabled?)
Yep its inside rcu_read_lock_bh().
The call rcu_read_lock_bh() already disabled BH (local_bh_disable()).
Thus, you can use the normal variants of skb_array_produce(), it is
(approx 20 cycles) faster than the _bh variant...
hah I was agreeing with you as in yep no need for the _bh variant :)
I must have been low on coffee or something when I wrote that response
because when I read it now it sounds like I really think the _bh is
needed.
At any rate _bh removed thanks!
From: John Fastabend <john.fastabend@gmail.com> Date: 2016-07-15 22:18:26
On 16-07-15 04:23 AM, Jesper Dangaard Brouer wrote:
On Thu, 14 Jul 2016 17:07:33 -0700
John Fastabend [off-list ref] wrote:
quoted
On 16-07-14 04:42 PM, Alexei Starovoitov wrote:
quoted
On Wed, Jul 13, 2016 at 11:23:12PM -0700, John Fastabend wrote:
quoted
This converts the pfifo_fast qdisc to use the alf_queue enqueue and
dequeue routines then sets the NOLOCK bit.
This also removes the logic used to pick the next band to dequeue from
and instead just checks each alf_queue for packets from top priority
to lowest. This might need to be a bit more clever but seems to work
for now.
Signed-off-by: John Fastabend <redacted>
---
net/sched/sch_generic.c | 131 +++++++++++++++++++++++++++--------------------
For this particular qdisc the performance gain should come from
granularityof spin_lock, right?
And the fact that the consumer and producer are using different
locks now.
Yes. Splitting up enqueue'ers (producer's) from the dequeuer (consumer)
is an important step, because today the qdisc layer have this problem
that enqueue'ers can starve the single dequeuer. The current
mitigation tricks are the enq busy_lock and bulk dequeue.
As John says, using skb_array cause producers and consumer to use
different locks.
quoted
quoted
Before we were taking the lock much earlier. Here we keep the lock,
but for the very short time.
original pps lockless diff
1 1418168 1269450 -148718
2 1587390 1553408 -33982
4 1084961 1683639 +598678
8 989636 1522723 +533087
12 1014018 1348172 +334154
I was able to recover the performance loss here and actually improve it
by fixing a few things in the patchset. Namely qdisc_run was
being called in a few places unnecessarily creating a fairly large per
packet cost overhead and then using the _bh locks was costing quite a
bit and is not needed as Jesper pointer out.
So new pps data here in somewhat raw format. I ran five iterations of
each thread count (1,2,4,8,12)
nolock (pfifo_fast)
1: 1440293 1421602 1409553 1393469 1424543
2: 1754890 1819292 1727948 1797711 1743427
4: 3282665 3344095 3315220 3332777 3348972
8: 2940079 1644450 2950777 2922085 2946310
12: 2042084 2610060 2857581 3493162 3104611
lock (pfifo_fast)
1: 1471479 1469142 1458825 1456788 1453952
2: 1746231 1749490 1753176 1753780 1755959
4: 1119626 1120515 1121478 1119220 1121115
8: 1001471 999308 1000318 1000776 1000384
12: 989269 992122 991590 986581 990430
nolock (mq)
1: 1435952 1459523 1448860 1385451 1435031
2: 2850662 2855702 2859105 2855443 2843382
4: 5288135 5271192 5252242 5270192 5311642
8: 10042731 10018063 9891813 9968382 9956727
12: 13265277 13384199 13438955 13363771 13436198
lock (mq)
1: 1448374 1444208 1437459 1437088 1452453
2: 2687963 2679221 2651059 2691630 2667479
4: 5153884 4684153 5091728 4635261 4902381
8: 9292395 9625869 9681835 9711651 9660498
12: 13553918 13682410 14084055 13946138 13724726
So then if we just use the first test example because I'm being a
bit lazy and don't want to calculate the avg/mean/whatever we get
a pfifo_fast chart like,
locked nolock diff
---------------------------------------------------
1 1471479 1440293 − 31186
2 1746231 1754890 + 8659
4 1119626 3282665 +2163039
8 1119626 2940079 +1820453
12 989269 2857581* +1868312
[*] I pulled the 3rd iteration here as the 1st one seems off
And the mq chart looks reasonable again with these changes,
locked nolock diff
---------------------------------------------------
1 1448374 1435952 - 12422
2 2687963 2850662 + 162699
4 5153884 5288135 + 134251
8 9292395 10042731 + 750336
12 13553918 13265277 - 288641
So the mq case is a bit of a wash from my point of view which I sort
of expected seeing in this test case there is no contention on the
enqueue()/producer or dequeue()/consumer case when running pktgen
at 1 thread per qdisc/queue. A better test would be to fire up a few
thousand udp sessions and bang on the qdiscs to get contention on the
enqueue side. I'll try this next. On another note the variance is a
touch concerning in the data above for the no lock case so might look
into that a bit more to see why we can get 1mpps swing in one of those
cases I sort of wonder if something kicked off on my test machine
to cause that.
Also I'm going to take a look at Jesper's microbenchmark numbers but I
think if I can convince myself that using skb_array helps or at least
does no harm I might push to have this include with skb_array and then
work on optimizing the ring type/kind/etc. as a follow up patch.
Additionally it does seem to provide goodness on the pfifo_fast single
queue case.
Final point is there are more optimizations we can do once the enqueue
and dequeue is separated. For example two fairly easy things include
removing HARD_TX_LOCK nn NICs with a ring per core and adding bulk
dequeue() to the skb_array or alf queue or whatever object we end up
on. And I expect this will provide additional perf boost.
Thanks,
John
On Fri, Jul 15, 2016 at 03:18:12PM -0700, John Fastabend wrote:
nolock (pfifo_fast)
1: 1440293 1421602 1409553 1393469 1424543
2: 1754890 1819292 1727948 1797711 1743427
4: 3282665 3344095 3315220 3332777 3348972
8: 2940079 1644450 2950777 2922085 2946310
12: 2042084 2610060 2857581 3493162 3104611
lock (pfifo_fast)
1: 1471479 1469142 1458825 1456788 1453952
2: 1746231 1749490 1753176 1753780 1755959
4: 1119626 1120515 1121478 1119220 1121115
8: 1001471 999308 1000318 1000776 1000384
12: 989269 992122 991590 986581 990430
So then if we just use the first test example because I'm being a
bit lazy and don't want to calculate the avg/mean/whatever we get
a pfifo_fast chart like,
locked nolock diff
---------------------------------------------------
1 1471479 1440293 − 31186
2 1746231 1754890 + 8659
4 1119626 3282665 +2163039
8 1119626 2940079 +1820453
12 989269 2857581* +1868312
...
Also I'm going to take a look at Jesper's microbenchmark numbers but I
think if I can convince myself that using skb_array helps or at least
does no harm I might push to have this include with skb_array and then
work on optimizing the ring type/kind/etc. as a follow up patch.
Additionally it does seem to provide goodness on the pfifo_fast single
queue case.
Agree. I think the pfifo_fast gains worth applying this patch set
as-is and work on further improvements in follow up.