On 2015-11-02 17:24, Eric Dumazet wrote:
On Mon, 2015-11-02 at 16:11 +0200, Denys Fedoryshchenko wrote:
Hi!
Actually seems i was getting this panic for a while (once per week) on
loaded pppoe server, but just now was able to get full panic message.
After checking commit logs on sch_fq.c i didnt seen any fixes, so
probably upgrading to newer kernel wont help?
I do not think we support sch_fq as a HTB leaf.
If you want both HTB and sch_fq, you need to setup a bonding device.
HTB on bond0
sch_fq on the slaves
Sure, the kernel should not crash, but HTB+sch_fq on same net device is
certainly not something that will work anyway.
Strange, because except ppp, on static devices it works really very well
in such scheme. It is the only solution that can throttle incoming
bandwidth, when bandwidth is very overbooked - reliably, for my use
cases, such as 256k+ flows/2.5Gbps and several different classes of
traffic, so using DRR will end up in just not enough classes.
On latest kernels i had to patch tc to provide parameter for orphan mask
in fq, to increase number for flows for transit traffic.
None of other qdiscs able to solve this problem, incoming bandwidth
simply flowing 10-20% more than set, but fq is doing magic.
The only device that was working with similar efficiency for such cases
- proprietary PacketShaper, but is modifying tcp window size, and can't
be called transparent, and also has stability issues over 1Gbps.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
