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.
Currently there is an XXX comment in the
Virt2Physstruct that mentions the need to invalidate LFT/UFT entries.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.