Re: [PATCH net-next RFC 0/5] Add NTF_EXT_AGED to control FDB ageing in SW or HW

[Andrew Lunn <andrew@lunn.ch>]

> Geunter had this question in the thread:
> 
> "I may be missing something, but I don't immediately see how this patch set
> helps me solve any of the problems I am seeing when integrating the Marvell
> switch code. Even if the switch internally does hardware aging, it still
> seems to me that we'll need software aging on top of that, even if the
> bridge code in the kernel has the same addresses in its fdb as the switch.
> I see no feasible means to keep the fdb in the switch synchronized
> with the fdb in the kernel".
> 
> You'll want to turn learning off on the bridge, and enable learning (and
> learning_sync) in hardware.  The hw driver will install an FDB entry in the
> bridge's FDB and mark it "external".  The entry will also appear in the
> device's FDB.

I don't think this is going to work. There is no efficient way to get
the hardware tables out of the hardware. We don't get notification of
additions or removals. We can only read the whole table. And it can be
expensive to read the whole table, since it can be 1K or more entries,
going over an MDIO bus, which in the worst case can be bit banging on
gpio lines.

We probably need a design for devices where we can efficiently get
access to the hardware table, and use it in the software bridge. But
we also need a design where the SW and HW bridges have independently
tables.

	Andrew