Date: Tue, 27 Aug 2019 22:20:02 +0300 From: Victor Gamov <vit@otcnet.ru> To: Eugene Grosbein <eugen@grosbein.net>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-net@freebsd.org Subject: Re: finding optimal ipfw strategy Message-ID: <f2aa4e0e-2339-d3e6-5a41-567b0c55b9e3@otcnet.ru> In-Reply-To: <c275f853-62a7-6bb7-d309-bf8a27d3dbae@grosbein.net> 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> <c275f853-62a7-6bb7-d309-bf8a27d3dbae@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/08/2019 21:46, Eugene Grosbein wrote: > 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? Eugene, Nothing special. loader.conf ===== machdep.hyperthreading_allowed="0" net.inet.ip.fw.default_to_accept=1 ===== sysctl.conf ===== net.link.ether.ipfw=1 net.link.bridge.ipfw=1 net.link.bridge.ipfw_arp=1 net.link.bridge.pfil_member=1 net.inet.ip.fw.verbose_limit=100 net.inet.ip.fw.verbose=1 ===== `sysctl net.isr` ===== sysctl net.isr net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.dispatch: direct ===== I don't know about internals but I think high interrupt load is bad and it because NIC does not support per CPU-queue for example. > If not, you should try something like this. For loader.conf: Sorry, it's a production system and I can reboot it at the middle of October only. > #substitute total number of CPU cores in the system here > net.isr.maxthreads=4 > # EOF Is it ok for multicast? It's UDP traffic which must be ordered. I read 'maxthreads=1' used to keep TCP traffic ordered. > 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. Yes, I read it already :-) Also some Calomel articles. I'll try to tune system at next reboot. The main question for myself now is "how is this architecture correct" and "how many traffic is possible to process". -- CU, Victor Gamov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f2aa4e0e-2339-d3e6-5a41-567b0c55b9e3>