On Tue, Feb 28, 2012 at 08:40:06PM -0800, John Fastabend wrote: > Also if there are embedded switches with learning capabilities they > might want to trigger events to user space. In this case having > a protocol type makes user space a bit easier to manage. I've > added Lennert so maybe he can comment I think the Marvell chipsets > might support something along these lines. The SR-IOV chipsets I'm > aware of _today_ don't do learning. Learning makes the event model > more plausible. net/dsa currently configures any switch chips in the system to do auto-learning. 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. 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? For net/dsa, we currently have: http://patchwork.ozlabs.org/patch/16578/ While I think this is conceptually sound, the implementation is hacky, and I wonder how you've solved it for your setup, and if DSA can piggy-back off that. -- 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
