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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
