Skip to content

Flow eviction and LFT/UFT lifecycle rework#990

Open
FelixMcFelix wants to merge 6 commits into
masterfrom
eviction-policy
Open

Flow eviction and LFT/UFT lifecycle rework#990
FelixMcFelix wants to merge 6 commits into
masterfrom
eviction-policy

Conversation

@FelixMcFelix
Copy link
Copy Markdown
Collaborator

This PR reworks the LFT/UFT lifecycle so that inbound/outbound entries are correctly bound by a single lifetime, and so that a slowpath packet tracks all LFTs which were used in its handling. We then associate this list of LFTs with the flow UFT, and the TCP flow entry if created.

This allows us to correctly keep LFTs alive so long as a UFT/TCP entry refers to them. This has been a longstanding bug. The new and really useful feature is that this allows us to remove all related and dependent entries when we deliberately evict an LFT to make space for a new flow.

An expiry policy for any table can now also specifiy an "eviction priority" for a given flow. Generally speaking most flows are unevictable so long as they are well-behaved, but the main issue is that we need information from elsewhere to know when we can make this determination. How we tackle this is by looking at all descendent flows which rely on a given flow. Most will state no preference on the flow lifecycle, but the TCP flow entry can return a non-zero priority when inactive in a given state for too long.

Closes #986.
Closes #788.
Closes #789.

@FelixMcFelix FelixMcFelix self-assigned this May 18, 2026
This PR reworks the LFT/UFT lifecycle so that inbound/outbound entries
are correctly bound by a single lifetime, and so that a slowpath packet
tracks all LFTs which were used in its handling. We then associate this
list of LFTs with the flow UFT, and the TCP flow entry if created.

This allows us to correctly keep LFTs alive so long as a UFT/TCP entry
refers to them. This has been a longstanding bug. The new and really
useful feature is that this allows us to remove all related and
dependent entries when we deliberately evict an LFT to make space for a
new flow.

An expiry policy for any table can now also specifiy an "eviction
priority" for a given flow. Generally speaking most flows are
unevictable so long as they are well-behaved, but the main issue is that
we need information from elsewhere to *know* when we can make this
determination. How we tackle this is by looking at all descendent flows
which rely on a given flow. Most will state no preference on the flow
lifecycle, but the TCP flow entry can return a non-zero priority when
inactive in a given state for too long.

Closes #986.
Closes #788.
Closes #789.
@FelixMcFelix FelixMcFelix marked this pull request as ready for review May 20, 2026 15:59
@FelixMcFelix
Copy link
Copy Markdown
Collaborator Author

From what I can tell this appears to have the same throughput on glasgow as master. I was mildly concerned that changing the Arc<TcpFlowEntryState> held by a UFT into a Weak<_> in the name of consistent leak prevention would have had a mild impact, due to the calls to Weak::upgrade (similar enough cost to an Arc::clone). Otherwise the extra work we're doing affects only the slowpath and the periodic reaper callback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant