LINUX.ORG.RU
ФорумAdmin

Вопрос к знатокам о классовой дисциплине PRIO из арсенала утилиты tc

 , ,


0

2

Всем привет! Хочу уточнить у знающих людей один момент по классовой дисциплине PRIO. Предысторию «зачем и почему» описывать не буду, дабы не утомлять большим количеством текста, перейду сразу к сути. По-умолчанию дисциплина PRIO создает 3 класса с приоритетами от 0 до 2 и распределяет трафик по меткам TOS, если нет заданных классификаторов или трафик не был классифицирован.

Мне для трафика, уходящего с интерфейса нужно создать 4 уровня приоритета, т.е. 4 класса, к примеру так:

tc qdisc add dev eth0 root handle 1: prio bands 4
Классифицировать трафик буду определенными фильтрами. Насколько я понимаю здесь получится 4 класса с приоритетом от 0 до 3. В эти классы я расфасовал трафик четырьмя фильтрами. Посмотрел - пакеты бегают в нужных классах.

Но вот правильно ли я понял следующий момент. Если трафик правильно классифицируется и попадает в нужные классы, то обрабатывается с приоритетом от 0 до 3 (соответственно для каждого класса), а неклассифицированный трафик обрабатывается по флагам TOS первыми 3мя классами: 1:1, 1:2, 1:3. Верно ли я это понимаю?

Или же все не так и нужно как то менять параметр priomap? Как его менять я честно говоря не понял. Нашел такой описание, а понять толком не могу, буду раз если кто-то поможет. :)

priomap classForPrio_0 classForPrio_1 ... classForPrio_15 This option defines a table which is used to assign a packet to a class based on its :priority:. It is only used if the packet is not assigned a class by a classifier. There is one entry in the table per packet priority, so the table has 16 entries. The first entry in the table contains the class number for priority 0 packets, the second entry contains the class number for priority 1 packets, and so on. Class number 0 means classid N:1, class number 1 means classid N:2, etc. The «priomap» option must be the last one in the command line. The «priomap» keyword is followed by the class numbers for each priority in asceding priority number order. If not specified this default priomap is used:

priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

If you supply less than 16 class numbers the ones you do supply are used to fill in the first entries in the table. The default map is used for the remaining entries.



Последнее исправление: gard (всего исправлений: 1)

Ну все, вроде разобрался... мой корявый перевод цитаты выше

priomap classForPrio_0 classForPrio_1... classForPrio_15

Эта опция определяет таблицу, которая используется для назначения пакету класса исходя из его «приоритета». Это используется только тогда, когда пакету не был присвоен класс классификатором. Здесь каждая запись в таблице определяет приоритет пакета, всего может быть 16 записей. Первая запись в таблице содержит номер класса для пакетов 0го приоритета, вторая запись содержит номер класса для пакетов 1го и так далее. Класс номер 0 означает classid N:1, класс номер 1 означает classid N:2 и т.д. Опция «priomap» должна быть последней в строке команды. Ключевое слово «priomap» определяет номера классов для каждого приоритета в соответствии с порядковым номером. Если значение не указано, то умолчально priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1. Если вы укажете меньше 16ти номеров классов они будут использоваться для заполнения первых записей в таблице. По умолчанию карта используется для остальных записей (прим. переводчика - видимо для записей, которые не были классифицированы фильтрами).

Вот еще цитата (с сайта Хакер, спасибо автору - Евгению Зобнину):

Классовая дисциплина prio предназначена для классификации трафика с помощью фильтров или приоритезации. По умолчанию prio содержит три класса, в каждом из которых находится обычная дисциплина FIFO. Когда сетевая карта обращается за очередным пакетом, проверяется класс :1. Если он не содержит пакетов, проверяется класс :2 и только в последнюю очередь - :3. Получается, что пакеты класса :1 получают наивысший приоритет, а :3 - наименьший. Решение о том, в какой класс направить трафик, дисциплина prio принимает на основе поля TOS сетевого пакета.

Получается что при добавлении следующей дисциплины:

tc qdisc add dev eth0 root handle 1: prio
рисуется следующая картинка
 TOS (0-15) 0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
    priomap 1   2   2   2   1   2   0   0   1   1   1   1   1   1   1  1   
 prio       |   |   |   
  0   1:1   |   |   |   
  1   1:2---+   |   |   
  2   1:3-------+---+   
Пакеты с TOS 0 будут отправлены в полосу с приоритетом 1, пакеты с TOS 1 будут отправлены в полосу с приоритетом 2... пакеты с TOS 6 будут отправлены в полосу с приоритетом 0.

Это поведение по-умолчанию. Его можно изменить, добавив опцию priomap, к примеру так:

tc qdisc add dev eth0 root handle 1: prio bands 4 priomap 0 1 2 3
Здесь заодно создается не 3, а 4 класса (максимум можно создать 16) с приоритетами 0-3. В умолчальной таблице priomap будут изменены первые 4 значения, вписанные здесь, остальные останутся умолчальными (TOS). И эти первые 4 значения будут определяться как classForPrio_0 classForPrio_1... classForPrio_15
 TOS (0-15) 0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
    priomap 0   1   2   3   1   2   0   0   1   1   1   1   1   1   1  1   
 prio       |   |   |   |
  0   1:1---+   |   |   |   
  1   1:2-------+   |   |
  2   1:3-----------+   |
  3   1:4---------------+
Если в команде добавления дисциплины задать priomap полностью (16 значений вместо 4х), то можно раскидать пакеты c метками TOS(0-15) уже по 4м классам. Значения здесь должны быть в пределах 0-3.

Но самое важное не это, это все относится только к распределению пакетов с метками TOS по некому количеству классов дисциплины PRIO, которую мы создали. Самое важное, что при наличии у нас фильтров, которые классифицируют трафик и отправляют его в классы 1:1 - 1:4 (в нашем случае будет 4 класса) - трафик будет обрабатываться по приоритетам, у класса 1:1 приоритет 0, у класса 1:2 приоритет 1... у класса 1:4 приоритет 3.

Получается что мои предположения в первом сообщении были верны. При наличии классификаторов, трафик идет в нужные классы, которые обрабатываются по их приоритету, а пакеты с меткой TOS, если не задавать priomap будут обрабатываться первыми 3мя классами. Вроде выходит, что TOS надо бы раскидать по всем классам (в данном случае по 4м), но вроде бы и нафиг оно надо, потому что метку TOS ставят не просто так и пусть эти пакеты и обрабатываются шустрыми первыми 3мя классами.

gard
() автор топика
Ответ на: комментарий от selivan

Рад, что пригодилось. Тоже сначала хотел использовать HTB + sfq, даже сделал все и оно работало, но потом передумал. У меня немного нестандартные условия задачи и мне кажется что выходит костыль. Есть шлюз, который условно говоря натит интернет (PPPoE 12Мбит/с, резерв также PPPoE 3Мбит/с) в локальную сеть. Поверх PPPoE есть PPTP-соединение, которое также натится. Кроме того на шлюзе есть шара. Мне нужно, чтобы в локальную сеть (с локального интерфейса на шлюзе) трафик передавался по следующим приоритетам (маркируется он в iptables):

  • prio 0 - транзитный трафик с Инета (PPPoE) от определенных внешних адресов (для работы вебинаров)
  • prio 1 - транзитный трафик, идущий с PPTP поверх PPPoE
  • prio 2 - весь остальной трафик с Инета
  • prio 3 - локальный трафик с шары на шлюзе (1Gbit/s)

То есть я режу не канал пользователям локальной сети, а пытаюсь приоритезировать приходящий с внешки трафик. И вот думаю, если сделать PRIO, на классы повесить SFQ + хэш по dst, то получится ли так чего-то добиться. По идее я просто создаю лишние очереди и хочу снизить скорость передачи неприоритетного трафика Извне на шлюз, чтобы быстрее получать приоритетный трафик. Сегодня все это проделал в качестве тестов, может быть и показалось, но на первый взгляд странички сайтов, с которых шел трафик в prio 0 открывались значительно быстрее, чем раньше.

Ну и потом меби сделаю PRIO на исходящий трафик PPPoE-интерфейса для некоторых портов (53, 80, 443 и пр..).

gard
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.