Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of flow table limits could be infallible #358

Open
bnaecker opened this issue Apr 27, 2023 · 0 comments
Open

Handling of flow table limits could be infallible #358

bnaecker opened this issue Apr 27, 2023 · 0 comments

Comments

@bnaecker
Copy link
Contributor

We addressed unwraps when OPTE hits limits adding new flows to the UFT in #347. However, during the discussion, starting here, we agreed that the approach the PR takes will solve the immediate problem but has some drawbacks. This issue tracks implementing other options, which should simplify the surrounding code.

In general, we'd like to make adding UFT entries infallible. That could be done by either having new entries displace the oldest ones. The UFT type needs to change significantly to do that, since we have no way of getting the "oldest" entry (or any entry by time) now. Another option would be to completely clear the UFT in this case. And a third would be to not add a UFT entry at all, but fallback to layer-processing all the new flows (until space is available perhaps).

The first option seems the best, but it does mean there's some thrashing and also requires the most code. The other options are simpler, but do mean that new flows (which probably are going to be used more than older ones) are slower. This issue does not cover perf or benchmarking, but having basic workloads that cover some of these cases would be very helpful here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant