Re: Best qdisc for interfaces of a firewall?

[Alan Goodman <notifications@yescomputersolutions.com>]

Surely pfifo is the least resource intensive?  If the device is already 
overloaded then I could not recommend any qdisc that does additional 
processing...

Alan

On 09/11/14 13:58, Dennis Jacobfeuerborn wrote:
> 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
>>
>>
>
> --
> 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
>