LINUX.ORG.RU

Multiqueue tuntap interface

 , ,


0

1

Узнал вот, что tuntap поддерживает такую фичу, решил попробовать.

Мой юзкейс - создаю очередь из 5 дескрипторов, первый используется ТОЛЬКО для записи пакетов в интерфейс, остальные 4 - ТОЛЬКО для чтения из своего потока.

Отправляю icmp для теста, в tcpdump вижу, что пакеты отправляются И принимаются интерфейсом, однако прикладной софт из дескрипторов, предназначенных для чтения ничего не получает. если же читаю из того же дескриптора, через который отправляю данные - все читается.

М.б я не правильно понял назначение этих очередей?

★★★★★

Ответ на: комментарий от vvviperrr

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

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

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

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

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

vel ★★★★★ ()
Ответ на: комментарий от vel

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

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

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

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

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

vvviperrr ★★★★★ ()
Ответ на: комментарий от vel

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

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

vvviperrr ★★★★★ ()
Ответ на: комментарий от vvviperrr

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

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

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

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

vel ★★★★★ ()
Ответ на: комментарий от vel

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

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

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

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

vvviperrr ★★★★★ ()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от vvviperrr

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

vel ★★★★★ ()
Ответ на: комментарий от vel

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

vvviperrr ★★★★★ ()
Ответ на: комментарий от vvviperrr

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

mky ★★★★★ ()
Ответ на: комментарий от mky

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

vel ★★★★★ ()
Ответ на: комментарий от vvviperrr

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

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

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

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

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

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

vvviperrr ★★★★★ ()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от vvviperrr

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

vel ★★★★★ ()
Ответ на: комментарий от mky

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

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

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

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

vvviperrr ★★★★★ ()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от vel

неправда

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

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

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

vvviperrr ★★★★★ ()
Последнее исправление: vvviperrr (всего исправлений: 1)
Ответ на: комментарий от vvviperrr

а где код

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

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

vel ★★★★★ ()
Ответ на: комментарий от vel

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, то я вообще ни откуда данные б не прочитал

vvviperrr ★★★★★ ()
Последнее исправление: vvviperrr (всего исправлений: 2)
Ответ на: комментарий от vvviperrr

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

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

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

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.