Hi Aaron,

thanks for the feedback.

Am Thu, Aug 06, 2026 at 10:57:38AM -0400 schrieb Aaron Conole:
> Felix Huettner <[email protected]> writes:
> 
> > All previous benchmarks did not test individual connections that
> > are quickly opened and closed across multiple zones. This allows us to
> > better evaluate how much conntrack is optimized for multithreading.
> > 
> > Below are some statistics based on this new benchmark. Each of them ran
> > 10 times and the Time listed here is the average over that.
> > 
> > | Threads | Connections | Zones | Data packets | Iterations | Time    |
> > | 10      | 10,000      | 100   | 0            | 100        | 113.4 s |
> > | 10      | 10,000      | 100   | 20           | 100        | 106.9 s |
> > | 10      | 10,000      | 1     | 0            | 100        | 110.6 s |
> > | 10      | 10,000      | 1     | 20           | 100        | 104.3 s |
> > | 10      | 10          | 100   | 20,000       | 100        | 27.7 s  |
> > | 10      | 10          | 1     | 20,000       | 100        | 23.7 s  |
> > | 10      | 50,000      | 10    | 20           | 100        | 189.4 s |
> > 
> > Signed-off-by: Felix Huettner <[email protected]>
> > ---
> > 
> > Notes:
> >     v3->v4: tcp flag logic fixes, general cleanup
> > 
> >  tests/test-conntrack.c | 285 +++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 285 insertions(+)
> 
> [...]
> 
> > +            if (packet_offset == 0) {
> > +                /* Check if something prevented a new connection to be 
> > added to
> > +                 * conntrack we should detect it here. This can generally
> > +                 * happen if the ct_sweep is too slow for all the 
> > connections
> > +                 * we generate. In this case we will just sleep a little 
> > and
> > +                 * then try again. */
> > +                if (pkt_batches[j]->packets[0]->md.ct_mark == 0) {
> > +                    xnanosleep(1000000);
> > +                    aux->sleep_counter++;
> > +                    j--;
> 
> I mentioned previously this can basically never converge, and you
> mentioned that it happened.  Please don't structure tests that if they
> are broken hang forever.  This could easily check that certain amount of
> time has passed, or track number of iterations.  Especially when you did
> encounter the issue in your own testing.

I'll add a break after 100s. That should still allow heavily loaded
testcases but also stops the test from hanging.

> 
> > +                    continue;
> > +                }
> > +                ovs_assert(ct_state & CS_NEW);
> > +            }
> 
> [...]
> 
> > +    /* Parse arguments */
> > +    n_threads = strtoul(ctx->argv[1], NULL, 0);
> > +    if (!n_threads) {
> > +        ovs_fatal(0, "n_threads must be at least one");
> > +    }
> > +    if (!str_to_ullong(ctx->argv[2], 0, &n_conns) ||
> 
> Why is n_threads treated special here?

Because there is no str_to_ulong. I just stole it from the testcases
above which also did that differently.

thanks,
Felix

> 
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to