Programming

Threads are not precisely a 'go faster' setting for your computer. You may be able to hand data off to a thread, but if the thread cannot keep up -- then what? You need to think of a strategy, not just throw in threads and hope.

Potential strategies:

No matter which strategy you pick, if you optimize the code, it will make everything easier.

JohnGraham,

The time to process each packet is definitely greater the average time between two packets arriving as the processing is actually done by the RANAP stack.
I will be dealing with sustained high levels of data.

Thank you for the link you have provided. I will analyze the available options different I will keep you posted about the further developments.

Thanks again for the input.

---------- Post updated at 03:11 PM ---------- Previous update was at 03:06 PM ----------

Yes. What you said makes a lot of sense...
Thanks for providing a different insight.

Yes, a master thread could pull packets from the socket and put them on one of N queues in rotation, for N threads to process. All N threads can access the same structured container, and can exploit multiple CPU cores. N should be the count of cores times 2. The process should be reusing the same buffers, allocated at startup, perhaps 4N or more, lowest first for locality of reference. Another thread might merge streams of used buffers from the N threads into one list of available buffers, fifo for locality of reference. You need mutex locks to control access to the fifo list, but the queues can be structured for simultaneous read and write, 2^n ring-buffer style. Welcome to multi-threading and buffering. Luckily, IP packet processing does not care if packets are reordered, so released packets can go into queues to a packet return demux thread that merges them into one queue for return to the stream. Hopefully the kernel / firewall API supposrts this flow.