В течение нескольких дней пытался завести эту шнягу. Поскольку поставил на запасной сервак xubuntu, а для нового ядра ESFQ не делают. Слышал, что есть каике-то переделанные, но я считаю, что это неправильно, поскольку разработчик сам сказал, что в новых ядрах сделали flow, и надо юзать его.
Ну так вот. Инфы по всему инету нашел я крупицы. Поэтому пришлось самому догонять. В принципе, решение было на поверхности, но мне видимо опыта и мозгов не хватило, чтобы сразу понять, как оно все делается.
Кароче, я надеюсь, что полученная мной информация кому-нибудь типа меня в будущем сэкономит время. Ну плюс еще м.б. я где-то накосячил и не до конца разобрался, так что надеюсь на критику.
Кароче, как я понял, эта вешается непосредственно на очередь SFQ(вырезка из моего скрипта):
$TC class add dev $LAN parent 1:20 classid 1:22 htb rate $((SPEED_IN/20))Kbit ceil $((SPEED_IN*4/5))Kbit prio 10
$TC qdisc add dev $LAN parent 1:22 handle 22: sfq perturb 10
$TC filter add dev $LAN parent 1:0 protocol all prio 15 handle 3 fw classid 1:22
$TC filter add dev $LAN parent 22: protocol all handle 22 flow map key dst and 0xff
С обычным фильтром не конфликтует - все нормально выбирается и делится.Единственное что я не понял, так это зачем ему handle, но без него ядро не принимает.
dst and 0xff означает, что в качестве идентификатора класса используется последний байт IP-адреса назначения.
Полученные классы прилепляются в качестве дочерних к классу, на котором висит очередь (либо к самой очереди, я хз. :) ) Т.е. имеют вид 22:12, 22:af, 22:f3 и т.д.
tc class show их периодически показывает. Они время от времени исчезают и появляются. До введения классификатора, SFQ их тоже генерил, но числа были какие попало.
С другими классами они не конфликтуют. Т.е. у меня в скрипте есть класс 1:12 и периодически генерится 28:12.
Далее. Некоторые говорят, что у них при включении flow перестают идти пакеты через интерфейс. Не знаю у всех ли так, но у себя я нашел причину в том, что нельзя вешать классификатор на дефолтный класс. Уж не знаю с чем это связано, но когда вешаю - интерфейс действительно блокируется. Поэтому на нем пришлось оставить обычный SFQ. Но учитывая, что класс этот с самым низким приоритетом и порезан по самое не балуйся, проблем быть не должно.
По ходу дела возникли непонятки с prio у фильтров. Как я понял, у вышестоящих классов prio обязательно должен отличаться от нижестоящих, иначе опять ругается ядро. Логично, что он должен быть больше, а не меньше, что я и сделал.
Ну вот вроде и все. С остальным проблем не возникло.