Hi Robert!
Robert Story (Coders) wrote:
1) A much more detailed analysis of all APIs in netsnmp is needed. The agent uses lots of functions from the base snmplib. There are globals that will need multi-threaded protection (the data-store stuff comes to mind).
That's defintely true, that has to be analyzed and documented in a future revision of my paper.
2) netsnmp_delegated_list is for requests that an individual handler has delegated in some way to another process. Those requests will be handled by those handlers, and no attempts at concurrent processing should be made.
Right, that has no sense to process the list concurrently.
3) handle_var_requests handles individual requests received in a PDU. I don't think that you can split these up for concurrent processing this high in the code flow. Packets with multiple requests are often for table rows, in which case some or all the requests are related and should be processed together.
jep, that's not really a performance gain, that's too high-level.
4) I think the idea that multi-threading can be added in the agent library, and the agent will suddenly be ready for high-performance operation is much to simplistic. (And if high-performance is really the goal, you should probably start with profiling the code to look for current bottlenecks that can be eliminated by optimizing the code in question.)
I agree with you, multithreaded != high-performance. Optimizing
code has to be done either, but I think performance could significantly benefit from concurrent OID processing. But the future will us show :)
The first step I would recommend would be to simply separate packet reception from packet processing. On thread would simply receive packets and put them in a queue for the second thread to process them. A fairly simple algorithm could check for duplicate packets (retries) received while the agent was busy processing a previous packet.
So I would think of handle_snmp_packet(). There is one thread (the
"main" thread) enqueuing the PDUs as you said in this function. And
signalling the worker threads that there are new requests. One worker
thread is processing the packet
(init_agent_snmp_session(), netsnmp_handle_request(), handle_pdu(), ...,
netsnmp_call_handlers()).
One problem is the concurrent access of the same handlers as you said, they have to be "mutexed".
Once that works, I would look into moving packet decoding into the reception thread. I don't think it would warrant it's own thread, as I expect that the decoding of packets to be fairly quick.
What do you mean with the decoding exactly?
The next step would be to move the initial grunt work of looking up the appropriate handler for each request into the packet reception thread as well. This gets into more concurrency issues, as now the registration tables are being accessed by two threads.
I think, that could be done in the worker threads.
Thank you for your feedback!
Hermann
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
