You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: