On Mon, 2012-02-13 at 07:13 -0800, John Fastabend wrote: > The use case here is multiple VFs but the same solution should work with > multiple PFs as well. FDB controls should be independent of how the ports > are exposed VFs, PFs, VMDQ/queue pairs, macvlan, etc. Makes sense. > With events and ADD/DEL/GET FDB controls we can solve both cases. This also > solves Roopa's case with macvlan where he wants to add additional addresses > to macvlan ports. Not familiar with that issue - I'll prowl the list. > Yes it should flood here, unless its acting as a 802.1Qbg VEB or VEPA. Ok. So there is a toggle somewhere which controls how flooding should happen. > > Maybe not. But the kernel already has the needed signals with one extra > hook we can save running a daemon in user space. Maybe that's not a great > argument to add kernel code though. You make a reasonable arguement to have it in the kernel but i think we win more if we separate the control. So while i empathize, I am hoping that youd go with the path that is hard to travel ;-> > The PF_BRIDGE:RTM_GETNEIGH,RTM_NEWNEIGH,RTM_DELNEIGH are registered in the > br_netlink_init() path. Hrm - hadnt paid attention to that before. Nasty. The bridge seems to be hard-coding policy on station movement, no? This is a good example of the qualms i have on adding things to the kernel;-> I may not want to auto update a MAC address moving ports as part of some policy i have. I can go and add YAK (Yet Another Knob) - but where is the line drawn? 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
