oxidecomputer / oxidecomputer/opte
Modifying a V2P mapping should invalidate LFT/UFT entries
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 77
- Forks
- 11
- Avg merge
- 9d 20h
- Merged PRs (30d)
- 8
Description
Currently there is an XXX comment in the Virt2Phys struct that mentions the need to invalidate LFT/UFT entries.
However,
// there is another problem that needs to be solved here: when a
// mapping is **MODIFIED** we need to invalidate any UFT/LFT entry
// that makes use of this virtual destination (for all Ports).
// That means updating the generation number of all Ports anytme
// an entry is **MODIFIED**.
Basically, all the OPTE Ports on a given host could have any number of LFT/UFT entries that contain a cached mapping of the destination's physical network address in the rack. If a guest changes location the mapping needs updating and any cached entries need to be invalidated and recomputed. The easiest way to do this is just bump the epoch of all the ports; but that's a large hammer, invalidating every flow entry in every port.
A better solution is to have some way to send a special message through the ports that invalidates any flows destined for the VIP being added/removed/modified. In fact, OPTE is overdue for the VFP feature of "simulating" a flow. Such a feature allows you to pretend to send traffic for a given flow for the purpose of either produce the side-effect of building LFT/UFT entires or for a case like this where you want to expire/remove any matching flows. This would allow one to selectively expire flows without the disruption of a full epoch change.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the XXX comment in the Virt2Phys struct and trace how LFT/UFT entries and per-port generation numbers are managed. Investigate the proposed VFP flow-simulation path for selectively expiring flows matching a modified VIP. Done means modifying a V2P mapping invalidates only affected entries across the relevant ports without a full epoch change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100