Le mercredi 03 novembre 2010 Ã 11:42 -0700, Justin Yaple a Ãcrit : > Yechiel, > > Again thank you this seems like a better fix than ignoring the error. > I had set the queue length to 1024 so it makes sense that the > buffersize would also need to be adjusted to acomidate the new queue > length. I have not figured out how to access the error message along > with the error number so I dont know for sure what it was. Its > probably safe to guess that because I was using the default buffer > space it was "bufferspace unavailible". > > #define BUFSIZE 4096 // Size of buffer used to store IP packets. > #define NFQLENGTH 1024 // Length of the netfilter queue. > > nfnl_rcvbufsiz(nfq_nfnlh(h), NFQLENGTH * BUFSIZE); > > So yes the kernel is sending packets to the queue faster than my > application was processing them but I expected that. The buffer does > need to be adjusted so the queue can hold those packets until they can > be processed. A single session did not run into this issue because > the default buffer size is large enough to hold any outstanding > packets of a single session but once multiple sessions were involved > the queue would fill up quickly. > > After that change I was able to handle running 32 parallel iperf > connections. The total throughput was ~20Mb. Without sending traffic > through my application the throughput was ~138Mb but given that all my > test systems are running as VMs on the same system with only 4GB of > ram it does not supprise me to see a big hit in performance there. > Should see better results running on dedicated hardware. If this is running on multi processor machine, you could use several NF queues (one per cpu). Eventually also use RPS if your network card is not multiqueue, to spread tcp flows to different cpus and different queues. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
