> Задача netmap/DPDK довести пакеты до процессора и вывести их в сеть, говорить,
> что обработка может драмматически падать глупо, так как это не относится
> к функциям netmap/dpdk.

От меня ускользает смысл этого аргумента, поскольку именно процессинг пакета и важен, а вовсе не только его получение или отправка.
Окей, мы можем с помощью DPDK и NETMAP быстро принять 40 mpps, например. А дальше их надо как-то классифицировать, обработать в соответствии с QoS и/или сделать изменения в заголовке пакета и отдать дальше - в сеть или приложению. И для этих операций нужно уже существенно больше процессорного времени, чем для простого получения или форвардинга.
Кстати, я несогласен не только с посылом такого аргумента, но и с содержанием: dpdk позволяет и QoS своими средствами делать, и ещё много чего, и работает этот функционал не быстро. Испробовано на собственной шкуре.

> В данном случае нужно рассматривать довод пакетов до userspace в случае netmap/dpdk,
> либо до switchdev в случае kernel. Фраза "чем попытка переложить на
> процессор " непонятна, где по вашему выполняется логика switchdev?

Именно что логика switchdev выполняется в kernel, но это только программирование железки. Весь процессинг пакета происходит в ASIC.
Это более ограниченная парадигма, чем DPDK или NETMAP, но существенно более производительная и менее энергозатратная.

> Если смотреть, на дальнейшую обработку с точки зрения удобства использования, я соглашусь,
> что использовать решение уже работающее в kernel проще, чем писать тоже
> самое с нуля для netmap/DPDK, но:
> * кто сказал что для netmap/DPDK нет готовых решений для "умной" обрабоки?
> * я не думаю, что писать/отлаживать логику в ядре проще чем в
> userspace, а значит если нужно будет докрутить switchdev на это скорее
> всего уйдёт больше времени.

DPDK хорошо подходит для, например, load-balancing на уровне приложения - это через switchdev не сделаешь. Однако, для use-case описанного в заголовке статьи, как мне кажется, он бы "зашёл" лучше.