[ovs-dev] [RFC 0/3] dpif-netlink: Introduce per-cpu upcall dispatching
Flavio Leitner
fbl at sysclose.org
Wed May 12 02:11:17 UTC 2021
Hi,
On Fri, Apr 30, 2021 at 11:31:26AM -0400, Mark Gray wrote:
> This series proposes a new method of distributing upcalls
> to user space threads attempting to resolve a number of
> issues with the current method.
>
I ran some tests with old V10, current master and this RFC
including the kernel (based on 5.11.0) on a 28 cores system.
The old v10 had the issue of not scaling up in case of a high
load of upcalls. The test sends a burst of UDP packets which
causes upcalls. The table below shows how many packets could
be sent without increasing the upcall loss counter.
v10 master rfc
packets 2k5 >55k 10k
So, it reproduced the same old v10 value. Regarding to branch
master then it's not determined due to test limitation. It is
at least above 55k (last time I think it was 63k). The RFC patch
resulted in a better number compared with v10 though the test
should be using only one thread as v10. I think that keeping
the CPU context could explain the difference.
Running the test with 8 parallel threads sending one burst of
UDP packets each resulted in the following table:
Branch missed lost
v10 52018 50288
master 52022 0
RFC 52021 0
Now the wake ups, one thread:
Branch wake processing
master 20+ 16+
RFC 3 1
Column wake: number of different threads receiving
sched:sched_wakeup or irq:softirq_entry.
Column processing: number of CPUs with double digits
usage.
And 8 parallel threads:
Branch wake processing
master 20+ 20+
RFC 10 8+
The results show that this new patch-set addressed the main
thundering herd issue and the scalability issue I reported
during V10 review.
Unfortunately I can review the patches only next week.
Thanks,
fbl
More information about the dev
mailing list