On 2/17/2012 6:28 AM, jamal wrote: > On Wed, 2012-02-15 at 17:26 -0800, John Fastabend wrote: >> On 2/15/2012 6:10 AM, Jamal Hadi Salim wrote: >>> On Tue, 2012-02-14 at 10:57 -0800, John Fastabend wrote: >>> >>>> Roopa was likely on the right track here, >>>> >>>> http://patchwork.ozlabs.org/patch/123064/ >>> >>> Doesnt seem related to the bridging stuff - the modeling looks >>> reasonable however. >>> >> >> The operations are really the same ADD/DEL/GET additional MAC >> addresses to a port, in this case a macvlan type port. The >> difference is the macvlan port type drops any packet with an >> address not in the FDB where the bridge type floods these. > > Ok. > [the vlan piece really should have been an integrated part of bridging; > in the early days this was the case] > > >> [root@jf-dev1-dcblab src]# br fdb help >> Usage: br fdb { add | del | replace } ADDR dev DEV >> br fdb {show} [ dev DEV ] >> >> In my example I just dumped all bridge devices, >> > > Ok, makes sense. > > >> Seems we need both a synchronize and a { add | del | replace } option. > > I am conflicted on this. > Not sure if that is a command line thing or something built into a user > space daemon. It may be useful to have the command line variant but i > feel having a daemon take care of things helps in faster > synchronization. > I think user space is a good spot to add such functionality (as opposed > to the kernel). That way user space can work with h/ware switching such > as yours as well as a standalone switching chips (from sillicon vendors > like Marvel etc). > IMO, the average user doesnt need to be aware of such low level stuff; > so the default should be for the user not to be responsible for > configuration of synchronization. IOW, I want to just run well > understood user interface tools things like ifconfig, ip link etc, the > new br tool and not even need to be aware that we are offloading. > So as long as s/w br0 is mapping to the bridge on ixgb-0 i dont need > to know ixgb0 h/w bridge exists. > Yes I agree that is the goal. > One last comment: > With synchronization there are other challenges when the entry in the > hardware conflicts with the entry in software when you intend the > behavior to be the same. This is not such a big deal with bridging but > becomes more apparent when you start offloading ACLs etc. > OK and these sorts of conflicts certainly don't need to be resolved by kernel code. So I think this is a reasonable reason to drive the synchronization into a user space daemon. > >> So I think what your saying is a per port bit to disable learning... >> hmm but if you start tweaking it too much it looks less and less like a >> 802.1D bridge and more like something you would want to build with tc or >> openvswitch or tc+bridge or tc+macvlan. > > These are pretty commodity features in most silicon switching chips ive > come across. You have a knob to control learning and another to control > flooding. > All right this looks like a follow up patch to me. First build the interface to configure the HW FDB. Then a second series to add a flooding knob which works for both embedded switches and software switches. > 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
