Там вообще-то тупо поинтер на кусок памяти, куда сетевуха силами DMA пакет положила. Пейлоад не копируется. Использованные sk_buff кладутся в пул и переиспользуются, а не деаллоцируются сразу.
А flow table в nft неслабо так путь по сетевому стеку срезает.
И вот как по мне, переписывание всех хелперов, протоколов, состояний и неизбежная реализация всего conntrack заново выглядит такой себе затеей.
А. Да. И по поводу своих неблокируемых per-core таблиц. Как будем хендлить вариант когда в одну сторону трафик прилетает на одно ядро, а в обратную на другое?

Там пара моментов возникла

1. Не получается во flowtable добавить больше 7 интерфейсов. Написал Пабло, он говорит ставь новое ядро. Не хочу новое ядро м)

2. Попробовал включить offload хотя бы на части вланов. Вроде нагрузка упала, но почему полез счётчик rx_dropped на сетевушке...? Без офлоада там ноль.

Слушай вот ты умничаешь.

А есть готовое решение для криворуких?
Или надобрать rdp скат

Все vlan приходящие в интерфейс прописаны в системе?

Нет, только 7 шт. Больше не дает, ругается

Нет, только 7 шт. Больше не дает, ругается

Странный у вас нат.

Так там видать с brasом совмещен нат, все в одном...

При оффлоаде не выйдет резать скорость и тд

Нет

Тогда и 7 интерфейсов бы хватило бы. По мне 2-3 на нате не совмещеном с сервером доступа достаточно...

А что актуальное есть нынче? на русском

Нету полноценного ничего.
Можно попробовать самые простые и популярные протоколы типа http, quic итд на xdp до стека ядра ловить и натить, а остальные ядру оставлять. Да, придется следить за тем, чтобы один внутренний ip и ядром и xdp натился в один внешний и ещё пару вопросов решить. Впрочем это вполне реально, а львиная доля трафика уже  будет силами xdp обрабатываться.

Переписывать же все нюансы и alg из линуксового стека на xdp это охренеть можно.

Уже устарела