On 11/11/2010 05:17 PM, Robert Story wrote: > On Thu, 11 Nov 2010 16:56:31 +0200 Timo wrote: > TT> I'm not too excited about caching cache changes. I'd prefer to just go > TT> ahead and update the cache directly. I'll try to brew up some code to > TT> see how it works out in practice. > > Ok. I suggest you put in some safety valves to make sure that netlink updates > don't starve other agent processing.
Right. In general, I think doing netlink listening of changes is way lighter than re-reading the neighbour table often (but the caching time is pretty large by default apparently). I'm now pretty okay with the code and understand how the existing stuff works, and what needs to be fixed. I still have one more implementation detail for which, I'd like to get a second opinion. Since I need to go break the arp data_access api and it will need to support both: cached polling and event changes listening we have some options: a) have two APIs in data_access/arp.h: one for periodic polling, one with callbacks for changes; each user (currently only inetNetToMediaTable) needs to support both APIs, and for polling do the detection of deleted entries as currently b) change data_access/arp.h to have only callback for changed entries. arp code needs to keep additional copy of the entries when polling (so it can detect deletions) c) as above, but supply find function for parent container, and add additional fields to netsnmp_arp_entry so the arp kernel provider can do update/deletions directly using the parent container d) make intermediate caching layer between users and the kernel providers. this is what net_snmp_search_update_prefix_info() does for ipv6 prefix stuff. however, i don't think is such a good approach for neighbour cache. e) other ideas? I personally would favor option C. That would minimize amount of temporary containers, and keep data in one place. It would also get rid of most duplicate code. However, it removes some of the abstraction that is currently in place (but do we really need it?). Cheers, Timo ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
