From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dennis Jacobfeuerborn Date: Sun, 09 Nov 2014 13:58:56 +0000 Subject: Re: Best qdisc for interfaces of a firewall? Message-Id: <545F7320.3090302@conversis.de> List-Id: References: <545EBBDE.3040200@conversis.de> In-Reply-To: <545EBBDE.3040200@conversis.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org The firmware is the current 1.5 release (well current before the very recent 1.6 one) so it's not really old. fq_codel is not in use and all interface use a noqueue qdisc. We are only using zone based firewalling, NAT and network/port groups so basically just iptables+ipset and a couple of vlan interfaces. In its default configuration both cpus are pegged at 95% soft-irq usage. Enabling vlan offloading reduces that quite a bit...but apparently make the system reboot itself about once every two days. On 09.11.2014 07:29, josh Reynolds wrote: > There is an issue on older firmware with edgerouterand fq_codel, Dave > would be the one to talk about that.. it's a codel/kernel thing though. > > I know wisps running full line rate and thousands of customers through > edgerouter pros with no problems. What are you having issues with? > > On 11/08/2014 03:57 PM, Dennis Jacobfeuerborn wrote: >> Hi, >> I just looked at the interfaces of our EdgeRouter Pro appliance that we >> plan to replace (due to it apparently being overloaded at 150Mbit) and >> see that they all have a qdisc of "noqueue". >> >> What is the best qdisc to select for a pure firewall system? I can't >> find any decent information about the various qdiscs and which to chose >> in specific situations. For example there seems to exist a multiq >> scheduler but I cannot find a lot of information about its >> characteristics plus I already assigned the irq of each queue of the nic >> to individual cores so I wonder if something like multiq is even >> necessary. >> >> I'm also wondering about fairness and if that might be a legitimate >> reason to chose somehting like noqueue so one flooding flow cannot hog >> the queue and penalize all other flows. >> >> Any ideas what would be a well performing yet fair choice here? >> >> Regards, >> Dennis >> -- >> To unsubscribe from this list: send the line "unsubscribe lartc" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >