Hi All, We have a project to adapt an existed firewall implementation to ODP framework. The current implementation needs to generate massive number of timer which link to each flow element. So there is requirement to run up to a million of timers to trigger the flow event.
An straightforward solution for us is to directly use ODP timer API to do the adaption. So we need to create individual timer for each flow element and attach a timeout event on. The advantage is the ODP event scheduling queue mechanism can help on a lockless flow processing for timeout event will be placed intp the same queue with packet belong to this flow. The prototype of this solution does work and it perfect fit our original processing flow. However, by carefully checking the ODP timer trigger mechanism, we find there could be performance issue when massive flow timer is created. The reason is current ODP timer implementation seems to run a full loop to check all active timers, regardless whether the timer will timeout in coming tick. So the worst situation is the timer_thread needs to check a million of timer tick buffer entries in each resolution interval. I do worry about it impacting the system performance or causing timer event losing. So by a general thought, is that a better way to distribute active timer entries to different tick buckets instead of putting in a large tick buffer pool? In each resolution interval, the timer system only checks expired tick bucket and flush timeout events attached to expired timers. In an example of setting resolution to 1/10 second and allowing up to 120 second relative timeout, a bucket table (size = 1200) is needed and the loop round could be reduced to 1/1200 comparing of current mechanism. The only trade off is a tick bucket table which need more memory plus a complex timer adding/reset algorithm comparing with current one. Let me know if I make some misunderstanding on current implementation. And thanks a lot for any comments. Mario Mao Software Engineer SonicWALL office +86 21 65100909 Ext: 42415
