LINUX.ORG.RU

Ограничение скорости Ethernet Bridge

 , , ,


1

4

Всем привет!

Завел я на своей кастомной плате OpenWRT. На плате 2 Ethernet 100Мбит, объединенные в мост. Все работает на малых скоростях, но как только начинаю тестировать скорость передачи по мосту или перекачивать большие файлы, вся система умирает.

Тестировал iperf3:

  • 10Мбит/полный дуплекс - норм, TCP и UDP по 9,5Мбит дают.
  • 100Мбит/полный дуплекс - UDP прокачивает 95Мбит/с, TCP кладет систему
  • 100Мбит/полудуплекс - UDP прокачивает 95Мбит/с, TCP - 75Мбит

На больших скоростях загруз проца почти 100 (95% обработка sirq)

Здоровенный лог падения приложу, если надо, но суть в том, что переполняется очередь отправки:

WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x198/0x224()
NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
Отсюда вопрос: как можно притормаживать Ethernet(из юзерспейса или в драйвере), чтобы избежать переполнения очереди?

P.S. Как я понял, проблема эта давняя, но нигде не могу найти нормального решения. Размеры очереди и обрезку кадров в драйвере менял - не помогло. Спасает только ограничение скорости да изменение дуплексности, но 10 Мбит или полудуплекс не хочется оставлять(плата тянет где-то 30Мбит).

Завел я на своей кастомной плате OpenWRT. На плате 2 Ethernet 100Мбит, объединенные в мост

что за процессор на плате - с этого надо начинать

На больших скоростях загруз проца почти 100 (95% обработка sirq)

ну так софтовый свитч - что вас так удивляет ?

Отсюда вопрос: как можно притормаживать Ethernet(из юзерспейса или в драйвере), чтобы избежать переполнения очереди?

man flow control (pause frame) но это все полумеры

anonymous
()
Ответ на: комментарий от vgovseychuk

Процессор i.MX287 в паре со 128 Мб оперативки. Слабоват, да.

а вы эррату на процессор не смотрели ? в первых i.MX28 был такой казус - EMAC-ки работают в big-endian а вся остальная система little-endian и единственно возможный workaround - каждый буфер разворачивать за счет CPU.

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

а вы эррату на процессор не смотрели ? в первых i.MX28 был такой казус - EMAC-ки работают в big-endian а вся остальная система little-endian и единственно возможный workaround - каждый буфер разворачивать за счет CPU.

Да, знаю такую проблему, но тут уж ничего не поделаешь.

vgovseychuk
() автор топика
Ответ на: комментарий от whoami

tc (traffic control) должен отлично завестись на bridge

Спасибо, видел где-то упоминания о нем. Буду пробовать

vgovseychuk
() автор топика

Попробуй выключить фильтрацию пакетов на бридже. И вообще выключи по максимуму все фичи, которые применимы к бриджу и жрут процессорное время.

Deleted
()
Ответ на: комментарий от I-Love-Microsoft

Своя плата на imx28??? Можно я потом обращусь с вопросами? Заканчиваем схему, будем разводить imx6s...

Чем смогу...

vgovseychuk
() автор топика
Ответ на: комментарий от Deleted

Попробуй выключить фильтрацию пакетов на бридже. И вообще выключи по максимуму все фичи, которые применимы к бриджу и жрут процессорное время.

Да вроде и так пообрезал.

Странная вообще тема. Линух пишет, что флоу-контрол есть, т.е. pause-кадры идут:

fec 800f0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
fec 800f4000.ethernet eth1: Link is Up - 100Mbps/Full - flow control rx/tx

Но раз очередь переполняется, значит не работает этот флоу-контрол. Или это для бриджа не применимо?

vgovseychuk
() автор топика
Ответ на: комментарий от vgovseychuk

Но раз очередь переполняется, значит не работает этот флоу-контрол. Или это для бриджа не применимо?

pause-frame - специальный фрейм, обычно генерируется аппаратно по заполнению приемного буфера до определенного порога, бридж/хренидж абстракция там в системе над ним или нет его не волнует. Тут затык может быть на стороне передающего - он может просто игнорировать эти фреймы - надо смотреть там ethtool-ом например.

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

Вот, что ethtool говорит (eth1 то же самое):

root@test:/# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes
И меня смущает «Supported pause frame use: No»

vgovseychuk
() автор топика
Ответ на: комментарий от vgovseychuk

Но раз очередь переполняется, значит не работает этот флоу-контрол. Или это для бриджа не применимо?

Возможно проблема в том, что система настолько занята обработкой входящего трафика, что на исходящий не остаётся процессорного времени.

Deleted
()
Ответ на: комментарий от vgovseychuk

ethtool -A eth0(eth1) rx on tx on - не помогло, упал все равно

vgovseychuk
() автор топика
Ответ на: комментарий от whoami

Завел трафик контроль на 30Мбитах. Не падает, вроде. Глубоко не вникал, поэтому покритикуйте скрипты, может, лучше можно:

tc qdisc add dev eth0 root handle 1:0 hfsc default 1
tc class add dev eth0 parent 1:0 classid 1:1 hfsc sc rate 30mbit ul rate 30mbit

tc qdisc add dev eth1 root handle 1:0 hfsc default 1
tc class add dev eth1 parent 1:0 classid 1:1 hfsc sc rate 30mbit ul rate 30mbit

vgovseychuk
() автор топика
Ответ на: комментарий от Deleted

Суть в том, что базовые механизмы, на которые опирается tc и так уже полюбому присутствуют и работают при передаче кадров в ядре: очереди, дисциплины и все такое. Вопрос лишь в том дефолтные ли они будут или настроенные как надо.

whoami
()
Ответ на: комментарий от vgovseychuk

Это слишком сложно и скорее всего не нужно, лучше оставить в инициализационных скриптах.

whoami
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.