Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

[jamal <hadi@cyberus.ca>]

On Mon, 2012-03-05 at 17:53 +0100, Lennert Buytenhek wrote:

> net/dsa currently configures any switch chips in the system to do
> auto-learning.  

So we clearly need the (user configurable) knob to turn on/off learning.
I think it should also be upto the admin to decide whether the learning
happens in the kernel or user space.
 
> However, I would much prefer to disable that, and have
> the switch chip just pass up packets for new source addresses, have
> Linux do the learning, and then mirror the Linux software FDB into
> the hardware instead -- that avoids having to manually flush the
> hardware FDB on certain STP state transitions or having to configure
> the hardware to use a shorter address learning timeout when we're in
> the middle of an STP topology change, which are problems we are
> running into in practice.

So in the scenario you are describing then it seems the h/ware has
no stp state toggles, correct? In other ASICs i have seen, there is
influence from stp state on behavior.

> Just curious -- while your patches allow propagating FDB entries
> into the hardware, do you also have hooks to tell the hardware which
> ports are to share address databases?

I think those are missing in this discussion and makes a lot of sense to
be part of the interface.

> net/dsa currently solves this by not having the hardware handle
> broadcast packets at all, which circumvents the problem, but for
> multicast traffic you would still like to be able to do at least the
> forwarding that can be done in hardware in hardware.  (Unicast doesn't
> have this problem as long as the kernel and the switch chip agree on
> their view of the FDB.)

Of course this could represent an interesting opportunity for a DOS.
Even at 4 port switch at 100Mbs, hitting 500Kpps to the CPU (I am
thinking these tiny switches end up in some tiny MIPS/ARM cpu) could
be devastating. How do you deal with that?

cheers,
jamal