On 3/5/2012 8:53 AM, Lennert Buytenhek wrote: > 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. > Great. And the plan is we should be able to use the same daemon with minimal changes (currently a flag) to control both sw and hw bridges. > 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? > Not in the current patches. I don't have hardware right now that can instantiate multiple bridges. When I get some I was hoping to do something similar to this patch and use netlink commands to create/delete bridges and add/remove ports to them. This would be modifying the existing commands to work for both software and hardware bridges. By a bridge instantiation I mean a shared address database in this case. > 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. Yep anything we come up with should work in both cases. -- 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
