Am Thu, Aug 06, 2026 at 10:57:20AM -0400 schrieb Aaron Conole:
> Felix Huettner <[email protected]> writes:
>
> > Previously we slept for a minimum of 200ms after each cleaning run, even
> > if we did clean the majority of entries. This originally came from the
> > requirement that we need to take the whole conntrack lock to cleanup
> > connections and are therefor limited in the progress we can still make
> > when inserting.
> >
> > However with the now implemented locks per zone and the batching this is
> > no longer needed. In addition before we could do partion zone cleanings
> > we always cleaned a full zone. This meant that a single high load zone
> > would still be cleaned quite fast.
> >
> > Signed-off-by: Felix Huettner <[email protected]>
> > ---
> > lib/conntrack.c | 26 +++++++++++++++++++-------
> > 1 file changed, 19 insertions(+), 7 deletions(-)
>
> [...]
>
> > @@ -1618,6 +1621,16 @@ conntrack_clean(struct conntrack *ct, long long now)
> > " entries in %lld msec", total_cleaned, count,
> > time_msec() - now);
> >
> > + /* If we did clean more than 10% of our connection limit we assume that
> > + * if we would continue we would also find a lot of connections to
> > clean.
> > + * In this case we want to rather continue immediately to ensure we get
> > + * the connections removed in a high load situation. */
> > + if (total_cleaned >= (clean_end / 10)) {
>
> I think we should also add some documentation for the user as well, in
> case they see some higher CPU load. Just a section in the NEWS entry
> about the 10$ of total conn clean limit. Perhaps we should also add a
> COVERAGE_ counter that tells we hit this 'big exhaustion' state. That
> way, if an operator sees high CPU, they have something to look at and
> rule in/out the ct cleanup mechanism.
>
> WDYT?
Sounds good. will be in the next version.
>
> > + next_wakeup = 0;
> > + } else {
> > + next_wakeup = MIN(next_wakeup, min_expiration);
> > + }
> > +
> > return next_wakeup;
> > }
> >
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
