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
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
