Date: Tue, 27 Aug 2019 00:15:01 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Victor Gamov <vit@otcnet.ru>, freebsd-net@freebsd.org Subject: Re: finding optimal ipfw strategy Message-ID: <cd72f9bf-a253-6a29-1405-1d31c9170836@grosbein.net> In-Reply-To: <a559d2bd-5218-f344-2e88-c00893272222@otcnet.ru> References: <f38b21a5-8f9f-4f60-4b27-c810f78cdc88@otcnet.ru> <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> <a559d2bd-5218-f344-2e88-c00893272222@otcnet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
26.08.2019 23:25, Victor Gamov wrote: > More general question about my current config. I have about 200Mbit input multicasts which bridged and filtered later (about 380 Mbit bridged if trafshow does not lie me :-) ) Don't trust trafshow. Use: systat -ifstat 1 > My FreeBSD box (12.0-STABLE r348449 GENERIC amd64) has one "Intel(R) Xeon(R) CPU E31270 @ 3.40GHz" and 4-ports "Intel(R) PRO/1000 PCI-Express Network Driver". HT disabled and traffic mainly income via igb0 and out both via igb0 and igb2. About 30 VLANs now active some at igb0 and some at igb2. > > > And I have following `top` stat: > ===== > CPU 0: 0.0% user, 0.0% nice, 80.5% system, 0.0% interrupt, 19.5% idle > CPU 1: 0.0% user, 0.0% nice, 34.1% system, 0.0% interrupt, 65.9% idle > CPU 2: 0.0% user, 0.0% nice, 17.1% system, 0.0% interrupt, 82.9% idle > CPU 3: 0.0% user, 0.0% nice, 46.3% system, 0.0% interrupt, 53.7% idle > ===== > > Also `vmstat -i |grep igb`: > ===== > irq264: igb0:rxq0 9310734762 5471 > irq265: igb0:rxq1 10186691956 5985 > irq266: igb0:rxq2 8190475727 4812 > irq267: igb0:rxq3 10063786697 5913 > irq268: igb0:aq 34 0 > irq273: igb1:aq 1 0 > irq274: igb2:rxq0 11010248236 6469 > irq275: igb2:rxq1 10843712062 6371 > irq276: igb2:rxq2 8810194905 5177 > irq277: igb2:rxq3 10975949272 6449 > irq278: igb2:aq 10 0 > irq283: igb3:aq 1 0 > ===== > > > Is it possible to get CPU load about 30% at this config after ipfw optimization? Or may be main bottleneck is not ipfw-specific? You won't know until you try and nobody can tell. Too many variables. And you better compare it with 11.3 because 12.0 may have some unsolved preformance regressions.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cd72f9bf-a253-6a29-1405-1d31c9170836>