по поводу медленной скорости работы

[legale]

Я сейчас ковыряюсь с примерно этим же самым. У меня модуль ядра туннельного eth интерфейса. Там не выполняется много магии, но определенные манипуляции с данными, которые снова нужно отправлять после изменения. Так вот я столкнулся с той же проблемой - слишком медленно работает.

Дело в использовании kernel_sendmsg
ret = kernel_sendmsg(rawsocket, &msg, &iov, 1, pktlen);

Таким способом выжать из моего туннеля удается не больше 10мбит при ширине канала 1гбит.

Вместо kernel_sendmsg нужно использовать udp_tunnel_xmit_skb в моем случае.

Что-то аналогичное супернизкоуровневое нужно использовать и здесь. Возможно dev_queue_xmit

Если заставить это работать должно стать побыстрее.

[legale]

надо сделать что-то такое:
перехватили пакет, сделали свои дела (желательно прямо в текущем skb), потом взяли этот же skb, где уже есть все и скормили его dev_queue_xmit(skb)

Ес-но возникает вопрос с чексуммами для iph и tcph, как-то там можно это также низкоуровнево пересчитать с максимальным использованием hardware ускорения.

[Waujito]

так скб ни кому не скармливается. Это хук нетфильтра. Если пакет не ютуба - просто пропускаем его дальше. Но вот если ютуб, то оригинальный skb дропаем, а дальше уже задействуем rawsocket с kernel_sendmsg. Я не думаю, что это критические потери.

Я изменил политику работы с skb в ветке kmod_fix. Теперь вместо linearize он маппится в буфер памяти. У меня это значительно увеличило производительность.