fasttrack x86

Думаю, это работает, но иногда не улучшает производительность так сильно, как на RouterBOARD.

Насколько я знаю, fasttrack — это фирменное решение Mikrotik, при котором трафик обрабатывается на уровне драйвера и не требует прохода через всю инфраструктуру ядра. Не путать с L3HW ускорением/выгрузкой.

«action=fasttrack-connection» активирует стандартный программный FastTrack, который должен работать практически везде. Он устанавливает специальный флаг в механизме отслеживания соединений (IP>Firewall>Connections), чтобы все последующие пакеты, относящиеся к этому соединению, обходили множество программных этапов, экономя ресурсы процессора. «hw-offload=yes» работает только если у вас есть устройство с коммутатором, поддерживающим L3HW Offload, и если на нем включена поддержка L3HW. Это «простой вариант» использования L3HW. По сути, когда механизм FastTrack «включается», он также программирует функции L3HW в чипе для обработки данного соединения, обходя процессор. (Однако это создаёт эквивалент «правила коммутатора» для каждого аппаратного fasttrack-соединения, поэтому существую относительно невысокие ограничения на общее количество соединений, которые можно обработать таким образом одновременно. Вручную настроенные «правила коммутатора» можно сделать так, чтобы они применялись ко всей категории соединений, что позволяет значительно увеличить объём аппаратного разгрузки.)

Я заметил значительное снижение нагрузки на CPU при использовании fasttrack на x86, когда работает довольно много правил фильтрации в цепочке forward, но это не так впечатляет, как на tile ccr с той интеграцией интерфейса, про которую ты говорил.

Я не читал исходный код, поэтому нет. Я основываю свои комментарии как на общедоступной информации, так и на собственных наблюдениях. Касательно последнего: если я запускаю ROS на x86, добавляю пару интерфейсов Intel E1000, убеждаюсь, что Fast Path включён и все требования выполнены (например, conntrack отключён, нет правил файрвола и т.п.), то в IP > Settings будет показано, что Fast Path активен, но счётчики останутся на 0 и не будут расти при передаче пакетов. Аналогично, если на том же роутере включить conntrack, добавить правило NAT masquerade и прописать соответствующее действие fasttrack-connection в фильтрах файрвола IPv4, Fast Path станет неактивен, Fast Track активируется в IP > Settings, и счётчики правила фильтра fasttrack в IP > Firewall > Filter будут увеличиваться. Но счётчики Fast Track в IP > Settings НЕ изменятся и останутся равны 0. Документация по обеим функциям чётко указывает, что они доступны только на определённом железе, и в некоторых случаях только на выбранных интерфейсах/портах на конкретных моделях (например, пакеты, идущие через ether12 или ether13 на RB1100, НЕ могут обрабатываться через Fast Path или Fast Track, и известно, что эти два порта на этой модели не связаны напрямую с SoC, а управляются отдельными сетевыми контроллерами, подключёнными к PCI-шине, как ясно показано на блок-схеме в руководстве (страница 10))! Это значит, что драйверы для соответствующих интерфейсов (ether1-ether11 в случае RB1100) были специально доработаны для поддержки. В той же документации ясно сказано, что Fast Track зависит от Fast Path… значит, если конкретный интерфейс (а значит и его драйвер) не поддерживает Fast Path, он не поддержит и Fast Track. Fast Track описывается как «обработчик» Fast Path:  
`FastTrack доступен > на устройствах с поддержкой FastPath >. FastTrack = FastPath + Connection Tracking.` (выделено мной)  
Сотрудник MikroTik в этом посте говорит о драйверах, которые «поддерживают» Fast Path. На слайде 12 презентации с прошедшего MUM по Fast Path чётко указано, что поддержка драйвера — обязательное требование:  
`FastPath — это > расширение драйвера интерфейса >, которое позволяет принимать/обрабатывать/отправлять трафик без лишней обработки.  
● > Драйвер интерфейса > теперь может напрямую взаимодействовать с определёнными процессами RouterOS, минуя остальные  
● Требования к FastPath: – > поддержка драйвера интерфейса […]`
В этом посте есть ссылка на ту же презентацию и делаются аналогичные утверждения в обсуждении поддержки Fast Path на RB850Gx2. К сожалению, я могу лично подтвердить, что RB850Gx2 не поддерживает ни Fast Path, ни Fast Track. Все интерфейсы 850Gx2 ведут себя точно так же, как интерфейс E1000 на x86. В итоге, конкретная поддержка должна быть добавлена в драйверы оборудования, чтобы соответствующий интерфейс на определённом роутере мог работать с Fast Path или Fast Track. Думаю, это не исключает возможности добавить поддержку Fast Path в драйверы Ethernet-интерфейсов на x86, но, судя по всему, MikroTik этого либо не сделал, либо сделал очень скромно — я так и не встретил распространённый PCI/PCIe Ethernet-чипсет с работающим Fast Path на x86. Хочу уточнить, что всё вышесказанное относится главным образом к ROS 6. Возможно, в ROS 7 ситуация изменилась.

Эх, моооожет быть? Но если это так, придется во время работы проверять кучу всего у потенциального драйвера, чтобы убедиться, что его безопасно поддерживать. Если предположить, что это действительно так, на месте разработчиков MT я бы просто вел белый список драйверов, которым разрешен Fast Path, потому что иначе какая-нибудь неожиданная реализация или баг в драйвере могут вызвать непредсказуемое поведение или проблемы, даже если в остальном он вроде подходит. В любом случае, это не какое-то невероятное или неслыханное событие, что MT патчит ethernet-драйверы. Они уже делают это, чтобы добавить поддержку L2MTU. Известно, что поддержка L2MTU явно нужна в драйвере, потому что интерфейсы на базе драйверов без этой поддержки показывают «0» как L2MTU, и это значение нельзя изменить... И у таких интерфейсов MTU по факту считается равным L2MTU.

Если бегло просмотреть патчи ядра RouterOS 6, то там есть очень небольшие обновления для минимальной поддержки L2MTU у некоторых драйверов стороннего (x86) оборудования, например, Intel e1000e. А некоторые драйверы, например ixgbe, по какой-то странной причине не получили такую (очень маленькую) доработку.

Так что, глянув очень поверхностно на патчи от MT (повторюсь, для ROS6, на базе Linux 3.3.5), я не совсем уверен, что они предоставили нам всё необходимое для понимания реализации Fast Path / Fast Track (но это всего лишь мой ОЧЕНЬ беглый осмотр). Совпадений с чем-то вроде «fast.*path» почти нет.

Одно, что стоит отметить — в структуру net_device_ops в netdevice.h добавлен указатель на функцию *ndo_fast_path_xmit(). Это очень сильно намекает на то, что драйвер устройства должен реализовать эту функцию, чтобы поддерживать Fast Path. Возможно, есть и универсальная версия, от которой можно унаследовать, но я пока её не заметил. (В той же структуре есть похожий указатель *ndo_change_l2mtu(), который, вероятно, нужно реализовать, прежде чем конкретный интерфейс позволит пользователю задавать или менять L2MTU.)

Хотя можно понимать это по-разному, лично я считаю, что когда MT в конце своей таблицы поддержки устройств Fast Path пишет «Other devices: Not supported», они хотят сказать не «Всё может быть», а то, что любое устройство, НЕ включённое в этот список — а это значит все x86 маршрутизаторы — — это жёсткое «нет».

Да, конечно. Именно это мы и обсуждаем. К сожалению, на данный момент у меня складывается ощущение, что мы (снаружи инженерии MT) не располагаем достаточными доказательствами, чтобы однозначно сказать «да» или «нет», и что мы оба можем смотреть на одни и те же данные и при этом вполне обоснованно прийти к диаметрально противоположным выводам. Например…

…Я не считаю твой вывод здесь неизбежным. Я с такой же легкостью могу утверждать, что отчёты Fast Path и Fast Track в ROS — это всего лишь индикатор того, что выполнены все «мягкие» требования (то есть нет пользовательской конфигурации — например, правил фильтрации в брандмауэре и т.п., — которые бы мешали работе, если бы аппаратно это действительно поддерживалось), а не однозначный знак того, что Fast-Path реально происходит. RB850Gx2, который как известно не поддерживает Fast Path, тоже будет показывать «ipv4-fast-path-active: yes» или «ipv4-fast-track-active: yes», как только [эти](https://wiki.mikrotik.com/Manual:Fast_Path#IPv4_handler) условия [будут выполнены](https://wiki.mikrotik.com/Manual:IP/Fasttrack#Requirements). Тут я соглашусь. 😂 Я не слышал и не знал о том, что в свежих ветках Linux появилось новое ядро поддержки L2MTU, но даже если это так, насколько я могу судить, глядя на патчи MikroTik к версии 5.6.3, они не используют никакой новой «родной» поддержки L2MTU. Большая часть их кастомных разработок L2MTU, которые были в патчах 3.3.5, кажется, просто перенесена почти в первозданном виде (+ там ещё есть новый «MPLSMTU», реализованный примерно так же).

Признаюсь, я совсем не спец по внутренностям ядра Linux, уж тем более в части сетевого стека. Тем не менее, кажется, что там происходит что-то большее, хотя я могу сильно неправильно всё интерпретировать (см. предыдущую фразу). Вот реальное определение функции, о которой идёт речь:

int (*ndo_fast_path_xmit) (struct net_device *dev, struct fp_buf *fpb);

То есть вызовы этой функции передают не обычный sk_buff вместе с dev-структурой, а какой-то другой буфер пакета (мета?-)структуру, который тоже (по всей видимости) новый. _**Чёрт побери**_, я так и не нашёл определение этой структуры нигде — ни в патчах MT, ни в полном исходном дереве Linux с применённым патчем. Структура объявлена вперёд (forward declaration) прямо перед определением net_device_ops в патче, чтобы можно было использовать её как параметр fast_path_xmit...

struct fp_buf;

struct net_device_ops {
[...]

…но это всё, что я смог найти. Определения структуры и её полей нет нигде. В принципе, возможно, что это просто алиас на sk_buff, но мы этого просто не знаем! Есть ещё несколько других структур, связанных с Fast Path, названия которых начинаются с «fp_», и многие из них тоже не имеют определений, за исключением fp_dev (кажется, что все остальные объявлены вперёд, так как поля fp_dev сделаны именно из этих типов):

struct fp_stuff;

struct fp_dev_pcpu_stats;

struct fp_stats_rcu;

struct fp_dev {
      struct fp_stuff *stuff;
      int (*xmit)(struct net_device *dev, struct fp_buf *fpb);
      struct hlist_node list;
      struct fp_dev_pcpu_stats __percpu *stats;
      struct fp_stats_rcu *stats_rcu;
      u64 sp_rx_packet;
      u64 sp_tx_packet;
      u64 sp_rx_byte;
      u64 sp_tx_byte;
      u64 fp_rx_packet;
      u64 fp_tx_packet;
      u64 fp_rx_byte;
      u64 fp_tx_byte;
      u64 tx_drop;
};

Видим, что это куча счётчиков и переменная с загадочным названием «stuff», хех. Похоже, что та же функция ndo_fast_path_xmit фигурирует и здесь, только под более коротким именем.

Структура fp_dev вложена в net_device:

struct net_device {
[...]
       unsigned                devid;
       struct fp_dev fp;
       unsigned long list_bitmap[256 / BITS_PER_LONG];

Однако я не нашёл ни одного места в исходниках Linux, где бы к dev.fp или dev->fp обращались или что-то с ним делали.

Также есть куча других заявленных функций, связанных с Fast Path, объявленных в include/linux/netdevice.h:

extern void (*fp_ptype_all_changed)(int);
extern void (*fp_nf_changed)(int, int pf);
extern void (*fp_xfrm_changed)(int);

Они экспортируются из net/core/dev.c. Но при этом **_на самом деле код всех этих функций отсутствует!_**

void (*ipv4_routing_changed)(void);
void (*fp_ptype_all_changed)(int);
void (*fp_nf_changed)(int, int pf);
void (*fp_xfrm_changed)(int);
EXPORT_SYMBOL(ipv4_routing_changed);
EXPORT_SYMBOL(fp_ptype_all_changed);
EXPORT_SYMBOL(fp_nf_changed);
EXPORT_SYMBOL(fp_xfrm_changed);

Я нашёл несколько вызовов этих функций разбросанных по коду, но реализации не нашёл. Это всё, что есть.

Наконец, есть ещё один указатель на функцию, добавленный в net_device_ops сразу под fast_path_xmit:

int (*ndo_xmit_commit) (struct net_device *dev);

Честно говоря, я не уверен, что это связано с Fast Path, но, наверное, да? Во всяком случае, я не нашёл ни одной реализации ни ndo_fast_path_xmit, ни ndo_xmit_commit вообще.

Так что либо я слеп как крот, либо MikroTik по какой-то причине оставил кучу нужного кода вне своих патчей GPL ядра.

К слову, у меня сохранился набор патчей ядра от кандидата на релиз версии 6.5, и ndo_fast_path_xmit там было определено так:

netdev_tx_t (*ndo_fast_path_xmit) (struct net_device *dev, struct net_device *port, void *buf);