On 2/28/2012 8:40 PM, John Fastabend wrote: > On 2/18/2012 4:41 AM, jamal wrote: >> On Fri, 2012-02-17 at 09:10 -0800, John Fastabend wrote: >> >>> 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. >> >> >> Yep. >> Thanks for listening John. Waiting to see them patches. >> >> cheers, >> jamal >> >> >> > > +Lennert > > OK back to this. The last piece is where to put these messages... > we could take PF_ROUTE:RTM_*NEIGH > > PF_ROUTE:RTM_NEWNEIGH - Add a new FDB entry to an offloaded > switch. > PF_ROUTE:RTM_DELNEIGH - Delete a FDB entry from an offlaoded > switch. > PF_ROUTE:RTM_GETNEIGH - Dumps the embedded FDB table > > The neighbor code is using the PF_UNSPEC protocol type so we won't > collide with these unless someone was using PF_ROUTE and relying on > falling back to PF_UNSPEC however I couldn't find any programs that > did this iproute2 certainly doesn't. And the bridge pieces are using > PF_BRIDGE so no collision there. > > I briefly thought about trying to pull the PF_BRIDGE protocol out > and use this for both types but I think its better to leave the > bridge code alone and there is also the issue of disambiguating a msg > at a port which has both an embedded switch and has SW bridge for a > master. Maybe I gave up too quickly here I could use a bit in the ndm_flags to specify embedded or sw bridge. But would require having the bridge module loaded. > > 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. > Just checked looks like the DSA infrastructure has commands to enable STP so guess it is doing learning. > The other mechanism would be to embed some more attributes into the > PF_UNSPEC:RTM_XXXLINK msg however I'm thinking that if we want to > support learning and triggering events then we likely also don't > want to send these events to every app with RTNLGRP_LINK set. > > Plus there is already a proliferation of LINK attributes and dumping > the FDB out of this seems a bit much but could be done with some > bitmasks. Although the current ext_filter_mask u32 doesn't seem to > be sufficient for events to trigger this. > > so much for a short note... > > Thanks > .John > > > > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
