On Sat, Nov 14, 2020 at 09:03:47AM -0800, Jakub Kicinski wrote: > On Sat, 14 Nov 2020 15:00:03 +0100 Tobias Waldekranz wrote: > > On Sat, Nov 14, 2020 at 12:59, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > If any of the flowtable device goes down / removed, the entries are > > > removed from the flowtable. This means packets of existing flows are > > > pushed up back to classic bridge / forwarding path to re-evaluate the > > > fast path. > > > > > > For each new flow, the fast path that is selected freshly, so they use > > > the up-to-date FDB to select a new bridge port. > > > > > > Existing flows still follow the old path. The same happens with FIB > > > currently. > > > > > > It should be possible to explore purging entries in the flowtable that > > > are stale due to changes in the topology (either in FDB or FIB). > > > > > > What scenario do you have specifically in mind? Something like VM > > > migrates from one bridge port to another? > > Indeed, 2 VMs A and B, talking to each other, A is _outside_ the > system (reachable via eth0), B is inside (veth1). When A moves inside > and gets its veth. Neither B's veth1 not eth0 will change state, so > cache wouldn't get flushed, right? The flow tuple includes the input interface as part of the hash key, so packets will not match the existing entries in the flowtable after the topology update. The stale flow entries are removed after 30 seconds if no matching packets are seen. New flow entries will be created for the new topology, a few packets have to go through the classic forwarding path so the new flow entries that represent the flow in the new topology are created.
