Как на адаптере установить режим Jumbo? (И что это такое?)

[MiK13]

Разрабатываем устройство обработки сигналов. Основной компьютер -- Zynq с процессором ARM.
Но информацию он получается по DMA от устройства предварительной обработки на базе ПЛИС Spartan. Которое принимает UDP пакеты от некоего измерительного устройства. Программирует эту ПЛИС другой человек. Я в этом программировании ничего не понимаю.
Это измерительное устройство выдаёт UDP пакеты двух типов: длиной примерно 1300 байтов и примерно 4000 байтов.
Для проверки я написал имитатор, который выдаёт аналогичные пакеты. И оказалось, что Spartan принимает только длинные.
Причём, выяснилось, что принимаются только фрагментированные пакеты. То есть если я ставолю MTU 1000, то принимаются и короткие пакеты, а если ставлю MTU 5000, то и длинные не принимаются.
Но разработчик программы для ПЛИС говорит, что у него принимаются и длинные и короткие. Причём нефрагментированные. А для этого он установил на своём ноутбуке (с виндой) для адаптера режим Jumbo. MTU не трогал.
Может быть и в линуксе можно установить режим Jumbo? И что это вообще за режим?
Исходное устройство, как выяснилось, выдаёт нефрагментированные UDP пакеты. Как короткие, так и длинные. Пока проверить с ним не получается.

[Aliech]

Код: Выделить всё

ip link set DEV mtu VALUE

и всех делов, а если так не работает, то надо удостоверится, что адаптер/драйвер вообще умеет большие кадры принимать

[MiK13]

Код: Выделить всё

ip link set DEV mtu VALUE

и всех делов

Как я понимаю, эта команда меняет MTU. Я его менял через ifconfig (она мне больше нравится, попробовал через ip -- результат аналогичный).
Но мне говорят про какой-то режим Jumbo.

P.S. Проверил на Zynq'е -- там не работает:

Shell

root@Zynq:~# ip link set eth0 mtu 2000
RTNETLINK answers: Invalid argument
root@Zynq:~# ifconfig eth0 mtu 2000
ifconfig: SIOCSIFMTU: Invalid argument

Там какой-то Petalinux. Чей это клон -- не знаю.

[chitatel]

Но мне говорят про какой-то режим Jumbo.

jumbo frame, наверное?

ИМХО, предложенной командой и активируется.

[Aliech]

Не "режим jumbo", коль пошла такая пьянка, а "jumbo frame". Само название как бы намекает, что речь про какой то "большой кадр". Короче, когда вы поставили больший mtu, это вы отправку больших кадров и разрешили. То, что в одной очень популярной ОС, которая не имеет отношения к данному форуму, есть отдельная кнопка/чекбокс с назвпнием "режим jumbo", так это только потому, что там сетевой стек скудней проработан, и почти все "интересное" скинуто в драйвера устройств. И на другом адаптере/драйвера этой кнопки/чекбокса может не быть, или он там по-другому будет называться. И не понятно, кстати, какого размера mtu именно эта опция задала на самом деле...

А у вас, если mtu не помогло, надо проверить, если поддержка вашей сетевухой "больших кадров". И да, а у вас там свитча нет в схеме коммутации? А он у вас с поддержкой jumbo frames? А какой у него и вашей сетевухи лимит размера кадров?

[Aliech]

P.S. Проверил на Zynq'е -- там не работает:

Shell

root@Zynq:~# ip link set eth0 mtu 2000
RTNETLINK answers: Invalid argument
root@Zynq:~# ifconfig eth0 mtu 2000
ifconfig: SIOCSIFMTU: Invalid argument

Там какой-то Petalinux. Чей это клон -- не знаю.

Ну всё, нет поддержки на zynq'е. Вам теперь надо понять, это драйвер или сама железка такая ущербная.

[yoricI]

А если включить на этом Zyng-е этот же режим ДЖумбо-фреймов, может и заработает.
У меня в логах:

Код: Выделить всё

May 19 14:16:04 [kernel] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]

Когда не было фирмвари, ругался, что недоступно. Подсунул, само сконфигурило.

[MiK13]

А если включить на этом Zyng-е этот же режим ДЖумбо-фреймов, может и заработает.
У меня в логах:

Код: Выделить всё

May 19 14:16:04 [kernel] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]

Когда не было фирмвари, ругался, что недоступно. Подсунул, само сконфигурило.

Мне это не нужно. У меня проблема как раз обратная.
В Zynq данные попадают из Spartan'а (ПЛИС). А в него должны приходить большие UDP пакеты. Причём, нефрагментированные.
Сейчас надо смоделировать работу.
И, как я понял. никакого специального "режима Jumbo" не существует.
Jumbo frame включается если я устанавливают MTU больше, чем 1500.
А проблема у меня другая. ПЛИС Spartan НЕ принимает нефрагментированные пакеты (по 1300 байт) А фрагментированные (по 4100 байт) принимает. Видимо это какая-то особенность его программы.
Если я делаю MTU 1200, чтобы и короткие пакеты фрагментировались, то Spartan их принимает.
При этом я заметил, что если я в ответ на принятую информацию выдаю её в сеть, то принимаются и короткие пакеты. Но только в том, случае, если этот выданные пакет фрагментирован.
Хотя, может быть, проблема и в другом месте...

[Aliech]

MiK13, попахивает кривой реализацией со стороны ПЛИСа. Пинайте разработчика (того, кто проектировал прошивку ПЛИСины).

Добавлено (21:20):

Когда не было фирмвари, ругался, что недоступно. Подсунул, само сконфигурило.

Ничего оно само не сконфигрурировало. А эта запись в dmesg'е говорит лишь о том, что после подсовывания фирмвари, доступен mtu до 9194 байтов. Но его включить должны вы. Оно само никакие jumbo никуда не включает. Вы по-прежнему остаётесь при 1500 байтах дефолтных, если иное не сконфигурили ручками.

[MiK13]

MiK13, попахивает кривой реализацией со стороны ПЛИСа. Пинайте разработчика (того, кто проектировал прошивку ПЛИСины).

Есть такое подозрение.
В устройстве две платы: одна -- Zynq, с процессором ARM и ещё ПЛИС. И вторая -- Spartan, на которой делается обработка сигнала. И которую делает один человек. И ещё один организовывает передачу по DMA из Spartan в Zynq. И, возможно, на этой стыковки что-то неправильно сделано.

[MiK13]

Приходил разработчик. Заставили ПЛИС принимать нефрагментированные пакеты.
Причём, когда он запускал имититор из под винды, пакеты принимались.
И, как я понял, причина в бите don’t fragment в заголовке IP пакета. Если IP пакет не фрагментирован, Linux этот бит устанавливает, а если фрагментирован, он в первом фрагменте устанавливает бит more fragments, а в последнем оба этих бита устанавливает в 0.
А винда бит don’t fragment не устанавливает.
Установили в настройках ПЛИС режим, чтобы он не проверял этот бит -- пакеты стали приниматься.
Но вот как в Линуксе сделать, чтобы бит don’t fragment был в нуле, я пока не разобрался.

[Aliech]

MiK13, а зачем в linux это поведение менять? Оно же корректное! У вас UDP, и отправитель ставит бит, запрещающий фрагментировать отправленный пакет. Как бы норма.

А вот по какой причине со стороны ПЛИСа есть такая реализация IP-стека, которая ТЕРЯЕТ пакеты входящие, которые поступают с вполне корректными значениями... вот это вопрос!

[MiK13]

MiK13, а зачем в linux это поведение менять? Оно же корректное! У вас UDP, и отправитель ставит бит, запрещающий фрагментировать отправленный пакет. Как бы норма.

Да, это норма. И разработчик программы для ПЛИС сказал, что ему пришлось повозиться, чтобы научиться получать фрагментированные пакеты. Но отсутствия бита don’t fragment не является некорректным. Он (как я понимаю) просто говорит, что данный пакет нельзя фрагментировать. Linux его устанавливает ("на всякий случай"), а винда нет. Поэтому у разработчика при отладке принимались все пакеты.
Устройство выдаёт по очереди короткий пакет (1300 байтов) и длинный (4000). Я в начале заметил, что принимаются только длинные (фрагментированные). Если я устанавливаю MTU 1000, то и короткие начинают приниматься (так становятся фрагментированными).
Но если при МТГ 1500 на вход попадают фрагменты каких-то других пакетов, то и короткие начинают приниматься.

В общем разработчик добавил в настройках бит, запрещающий проверку битов флагов IP пакетов и проблема решилась.
Хочется, конечно, научиться управлять битами флагов IP пакета, но пока не получается.

[Bizdelnick]

By default, Linux UDP does path MTU (Maximum Transmission Unit) discovery. This means the kernel will keep track of the MTU to a specific target IP address and return EMSGSIZE when a UDP packet write exceeds it. When this happens, the application should decrease the packet size. Path MTU discovery can be also turned off using the IP_MTU_DISCOVER socket option or the /proc/sys/net/ipv4/ip_no_pmtu_disc file; see ip(7) for details. When turned off, UDP will fragment outgoing UDP packets that exceed the interface MTU. However, disabling it is not recommended for performance and reliability reasons.

Никаких «на всякий случай».

[MiK13]

By default, Linux UDP does path MTU (Maximum Transmission Unit) discovery. This means the kernel will keep track of the MTU to a specific target IP address and return EMSGSIZE when a UDP packet write exceeds it. When this happens, the application should decrease the packet size. Path MTU discovery can be also turned off using the IP_MTU_DISCOVER socket option or the /proc/sys/net/ipv4/ip_no_pmtu_disc file; see ip(7) for details. When turned off, UDP will fragment outgoing UDP packets that exceed the interface MTU. However, disabling it is not recommended for performance and reliability reasons.

Никаких «на всякий случай».

Поэтому я и взял это в "кавычки"
Но из этого текста я понял, что Linux перед тем, как что-то послать, проверяет дойдут ли пакеты данного размера до конечного адреса. И если обнаружит, что не дойдут, то возвращает EMSGSIZE. И если это отключить, то он для фрагментации будет руководствоваться только MTU адаптера. Хотя я не понимаю почему это не рекомендуется отключать.
Натолкнулся на одно обсуждение, в котором говорилось, что какое-то устройство не отвечало на пакеты, в которых установлен DF бит.
Но с рекомендацией как его убрать (с помощью tc) я пока не понял.
А к нас оказалось, что устройство не хотело принимать пакеты с установленным битом DF. Причём, устройство чисто пассивное. Чтобы послать на него информацию приходится через arp задавать его MAC-адрес.

[Bizdelnick]

Хотя я не понимаю почему это не рекомендуется отключать.

for performance and reliability reasons.

Но с рекомендацией как его убрать (с помощью tc) я пока не понял.

На кой чёрт Вам tc, сказано же:

Path MTU discovery can be also turned off using the IP_MTU_DISCOVER socket option

man setsockopt