On Sat, 21 Nov 2020 13:31:38 +0100 Pablo Neira Ayuso wrote: > On Mon, Nov 16, 2020 at 11:56:58PM +0100, Pablo Neira Ayuso wrote: > > On Mon, Nov 16, 2020 at 02:45:21PM -0800, Jakub Kicinski wrote: > > > On Mon, 16 Nov 2020 23:36:15 +0100 Pablo Neira Ayuso wrote: > > > > > Are you saying A -> B traffic won't match so it will update the cache, > > > > > since conntrack flows are bi-directional? > > > > > > > > Yes, Traffic for A -> B won't match the flowtable entry, this will > > > > update the cache. > > > > > > That's assuming there will be A -> B traffic without B sending a > > > request which reaches A, first. > > > > B might send packets to A but this will not get anywhere. Assuming > > TCP, this will trigger retransmissions so B -> A will kick in to > > refresh the entry. > > > > Is this scenario that you describe a showstopper? Sorry I got distracted. > I have been discussing the topology update by tracking fdb updates > with the bridge maintainer, I'll be exploring extensions to the > existing fdb_notify() infrastructure to deal with this scenario you > describe. On my side this topology update scenario is not a priority > to be supported in this patchset, but it's feasible to support it > later on. My concern is that invalidation is _the_ hard part of creating caches. And I feel like merging this as is would be setting our standards pretty low. Please gather some review tags from senior netdev developers. I don't feel confident enough to apply this as 100% my own decision.
