Multiqueue tuntap interface

никто не сталкивался?

А ты при этом на всех дескрипторах выполняешь чтение ?

Думаю, что в другие дескрипторы данные будут попадать по мере заполнения приемных буферов.

Я бы для проверки послал снаружи кучу больших пингов, а на приемной стороне читал бы из дескрипторов с паузой в Х-секунд или просто сделал паузу, а потом посмотрел сколько пакетов попали в каждый из дескрипторов.

IMHO Multiqueue на передачу удобно если данные формируются из нескольких мест или нужно обеспечить скорость передачи данных больше, чем позволяет 1 поток.

IMHO на прием multiqueue нужен если 1 поток не успевает обрабатывать входящие данные.

А ты при этом на всех дескрипторах выполняешь чтение ?

яж говорю, читаю только их четырех, а пишу в один.

IMHO на прием multiqueue нужен если 1 поток не успевает обрабатывать входящие данные

я и не успеваю. нужно прочитать данные, распарсить ip заголовок, обработать данные. хотел городить обычные треды с tls буфером, а тут прочитал про такую фишку.

вобщем опытным путем выяснил, что название говорит само за себя. на каждый дескриптор приходится отдельная очередь, притом что эти очереди не пересекаются. т.е если посылать данные только в один дескриптор, то и прочитать ответ можно только через него, в других будет всегда пусто. что странно, т.к не понятно, как модуль понимает, в какую очередь положить вновь полученный пакет.

Думаю, что в другие дескрипторы данные будут попадать по мере заполнения приемных буферов.

еще раз, пишу в один, читаю из ОСТАЛЬНЫХ четырех. данных нет ВООБЩЕ. они попадают в очередь первого дескриптора (из которого я не читаю). как - одному торвальдсу известно. код модуля с наскока не осилил.

я и не успеваю. нужно прочитать данные, распарсить ip заголовок

т.е. в ifconfig видны дропы на приеме через этот тап?

А не пробовал включить RPS/XPS для tap ?

типа «echo F >/sys/class/net/tapX/queues/rx-0/rps_cpus» ?

т.е. в ifconfig видны дропы на приеме через этот тап?

нет. просто в случае с несколькими пользователями туна начинается конкуренция. пока первого не обработают ко второму не смогут приступить.

https://github.com/vvviperrr/SimpleRT/blob/multi_tether/simple-rt-cli/src/net...

вопрос тащемта не в этом был. я понимаю как это разрулить на потоках. вопрос именно о специфичном поведении multiqueue.

гм, что-то я «ifr.ifr_flags = IFF_ATTACH_QUEUE; ioctl(fd, TUNSETQUEUE,&ifr)» там не заметил.

я просто указал на ботл нек текущей реализации. а с multiqueue каждый поток бы читал из своего tun дескриптора.

Вы и проверьте специфичное поведение, то есть посылайте пакеты и не читайте из первого, пока они не начнутся дропаться, если и при этом они не появятся на втором дескрипторе, значит что-то странное.

По исходникам не видно, чтоб он подключал несколько очередей.

https://github.com/vvviperrr/SimpleRT/blob/test/simple-rt-cli/src/network.c#L102

а отправляю всегда в первый

https://github.com/vvviperrr/SimpleRT/blob/test/simple-rt-cli/src/network.c#L217

я не заметил, чтоб приложение открывало несколько раз устройство и подключало к ним multiqueue

Прочитай linux/Documentation/networkin/tuntap.txt

выше, в ветке test

Прочитай linux/Documentation/networkin/tuntap.txt

читал, там ничего не сказано о таком поведении

У тебя 1 дескриптор и несколько тредов. Для работы с multiqueue нужно несколько дескрипторов.

Вы и проверьте специфичное поведение, то есть посылайте пакеты и не читайте из первого, пока они не начнутся дропаться, если и при этом они не появятся на втором дескрипторе, значит что-то странное.

сейчас так и делаю. пишу в первый, читаю из второго. данные на втором НЕ появляются, пакеты дропаются

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.1.1.1  netmask 255.255.255.0  destination 10.1.1.1
        inet6 fe80::a53d:13d9:e913:2d89  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 1457  bytes 99959 (97.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 79  bytes 8972 (8.7 KiB)
        TX errors 0  dropped 500 overruns 0  carrier 0  collisions 0

но как я уже сказал, очевидно это нормальное поведение. удивительно правда, как драйвер понимает, в какую очередь класть новый пакет.

неправда

https://github.com/vvviperrr/SimpleRT/blob/test/simple-rt-cli/src/linux/tun.c...

вот создаю 5 дескрипторов, пишу в первый, на остальные вешаю треды-читалки.

внимательнее, версия с multiqueue только в ветке test!

а где код

ifr.ifr_flags = IFF_ATTACH_QUEUE; 
ioctl(fd, TUNSETQUEUE,&ifr)

для каждого полученного дескриптора ?

IFF_ATTACH_QUEUE

https://www.kernel.org/doc/Documentation/networking/tuntap.txt

  A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When
  calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when
  calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were
  enabled by default after it was created through TUNSETIFF.

The queue were enabled by default after it was created through TUNSETIFF

если бы они все были бы disabled, то я вообще ни откуда данные б не прочитал

https://github.com/torvalds/linux/blob/master/drivers/net/tun.c#L457

вобщем да, очереди определяются на основе хеша. это нормальное поведение.

ну, поверим документации :)

Ты сам себе пакет посылаешь ? А если с другой машины/netns ?

IMHO При маршрутизации через localhost без явного разрешения RPS/RFS/XPS multiqueue не будет работать.

с другой машины