On 10/13/2011 02:29 PM, abirvalg@xxxxxxxxxxx wrote: > In my app one thread sends packets to NFQUEUE and another thread processes that \ > NFQUEUE at the rate of 10 packets per second. I watch the state of NFQUEUEs using \ > watch -n 1 'cat /proc/netnetfilter/nfnetlink_queue' I noticed that if I \ > nfq_set_queue_maxlen to 299, then when the queue fills up to 299 (3rd column), the \ > overflow gets dropped. As soon as new packets cease to arrive, dequeuing begins at \ > the rate of 10 per second until the 3rd columnn reaches 0. All as expected. > But as soon as I set NFQUEUE maxlen to 300, the following happens - the overflow \ > gets dropped; but when I stop generating new packets, no dequeuing is taking place, \ > the 3rd column seems to be stuck on 299 and from then on packets for that NFQUEUE \ > don't get queued anymore but are dropped instead. The NFQUEUE still processes \ > packets at the rate of 10 per second, but instead of queuing the overflow, it \ > simply drops it. > Is this a bug or a feature? Sure seems like a bug to me. >Are you using some form of lock (like a mutex) to protect your nfq >calls? In my experience you need those. Thank you for you suggestion. It didn't work, alhough I held my breath for a second. I inserted pthread_mutex_lock ( &nfqrepeat_mutex ) at the start of the queue handler and pthread_mutex_unlock ( &nfqrepeat_mutex ) right before return 0; This time around the 3rd column did overcome the vicious 299 figure but stuck on 359 and exhibited the same begaviour as I described above when it would get stuck on 299. Some kind of voodoo going on? -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
