Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Aug 2019 01:46:03 +0700
From:      Eugene Grosbein <eugen@grosbein.net>
To:        "Andrey V. Elsukov" <bu7cher@yandex.ru>, Victor Gamov <vit@otcnet.ru>, freebsd-net@freebsd.org
Subject:   Re: finding optimal ipfw strategy
Message-ID:  <c275f853-62a7-6bb7-d309-bf8a27d3dbae@grosbein.net>
In-Reply-To: <ddaa55bc-1fa5-151b-258e-e3e9844802ef@yandex.ru>
References:  <f38b21a5-8f9f-4f60-4b27-c810f78cdc88@otcnet.ru> <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <a559d2bd-5218-f344-2e88-c00893272222@otcnet.ru> <ddaa55bc-1fa5-151b-258e-e3e9844802ef@yandex.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
28.08.2019 1:03, Andrey V. Elsukov wrote:

> As you can see, when ipfw produces high load, interrupt column is more
> than system.

Interrupt numbers higher than others generally mean that traffic is processed without netisr queueing mostly.
That is expected for plain routing. I'm not sure if this would be same in case of bridging.

Victor, do you have some non-default tuning in your /boot/loader.conf or /etc/sysctl.conf?
If yes, could you show them? If not, you should try something like this. For loader.conf:

hw.igb.rxd=4096
hw.igb.txd=4096
net.isr.bindthreads=1
net.isr.defaultqlimit=4096
#substitute total number of CPU cores in the system here
net.isr.maxthreads=4
# EOF

For /etc/sysctl.conf:

dev.igb.0.rx_processing_limit=-1
dev.igb.1.rx_processing_limit=-1
net.inet.ip.intr_queue_maxlen=40960

And if you haven't already seen it, you may find useful my blog post
(in Russian) https://dadv.livejournal.com/139170.html

It's a bit old but still can give you some light.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c275f853-62a7-6bb7-d309-bf8a27d3dbae>