Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1424275
| From | Eric Dumazet <edumazet@google.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq |
| Date | 2016-06-16 19:00 +0200 |
| Message-ID | <rKIO6-2nS-11@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <rKmaR-4Zj-1@gated-at.bofh.it> <rKmue-5m4-11@gated-at.bofh.it> <rKD21-7fn-5@gated-at.bofh.it> <rKDv4-7Hj-25@gated-at.bofh.it> <rKEhr-8cw-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
>
> I guess you means 'consumer' here. The scheduler doesn't fail to migrate
> it: the consumer is actually migrated a lot of times, but on each cpu a
> competing and running ksoftirqd thread is found.
>
> The general problem is that under significant network load (not
> necessary udp flood, similar behavior is observed even with TCP_RR
> tests), with enough rx queue available and enough flows running, no
> single thread/process can use 100% of any cpu, even if the overall
> capacity would allow it.
>
Looks like a general process scheduler issue ?
Really, allowing the RX processing to be migrated among cpus is
problematic for TCP,
as it will increase reorders.
RFS for example has a very specific logic to avoid these problems as
much as possible.
/*
* If the desired CPU (where last recvmsg was done) is
* different from current CPU (one in the rx-queue flow
* table entry), switch if one of the following holds:
* - Current CPU is unset (>= nr_cpu_ids).
* - Current CPU is offline.
* - The current CPU's queue tail has advanced beyond the
* last packet that was enqueued using this table entry.
* This guarantees that all previous packets for the flow
* have been dequeued, thus preserving in order delivery.
*/
if (unlikely(tcpu != next_cpu) &&
(tcpu >= nr_cpu_ids || !cpu_online(tcpu) ||
((int)(per_cpu(softnet_data, tcpu).input_queue_head -
rflow->last_qtail)) >= 0)) {
tcpu = next_cpu;
rflow = set_rps_cpu(dev, skb, rflow, next_cpu);
}
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 0/5] genirq: threadable IRQ support Paolo Abeni <pabeni@redhat.com> - 2016-06-15 15:50 +0200
[PATCH 4/5] netdev: implement infrastructure for threadable napi irq Paolo Abeni <pabeni@redhat.com> - 2016-06-15 15:50 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq kbuild test robot <lkp@intel.com> - 2016-06-15 16:20 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq Eric Dumazet <edumazet@google.com> - 2016-06-15 16:20 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq Eric Dumazet <edumazet@google.com> - 2016-06-15 16:30 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq Paolo Abeni <pabeni@redhat.com> - 2016-06-15 18:50 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq Eric Dumazet <edumazet@google.com> - 2016-06-15 19:10 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq Paolo Abeni <pabeni@redhat.com> - 2016-06-16 12:50 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq Eric Dumazet <edumazet@google.com> - 2016-06-16 13:20 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq Paolo Abeni <pabeni@redhat.com> - 2016-06-16 14:10 +0200
Re: [PATCH 4/5] netdev: implement infrastructure for threadable napi irq Eric Dumazet <edumazet@google.com> - 2016-06-16 19:00 +0200
csiph-web