[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