Ethernet: насколько распространена поддержка Flow control?, (xon/xoff) Делать поддержку, или не делать. Опции

[Koluchiy]

Здравствуйте, уважаемые гуру.

Делаю девайс, который, если в общих чертах, принимает пакеты Ethernet, кладет их в FIFO, вынимает из FIFO и без изменения кидает дальше.

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

Один из путей решения проблемы - использование механизма Flow Control - а именно, слать передающему девайсу Pause фреймы в случае, если FIFO почти заполнилось.

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

Насколько велика вероятность того, что посланный Pause фрейм найдет понимание в оборудовании, сопряженном с моим.

Заранее спасибо за ответы.

[Rst7]

Я вот читаю описание PAUSE пакета и вижу, что MAC адреса, и Dst, и Src, очень даже используются. Причем, Dst может указывать на конкретный хост в сети, который надо тормозить.

Простите, где Вы такое читаете? DST там всегда равен служебному адресу, что и определяет, что пакет есть PAUSE.

[Aprox]

Простите, где Вы такое читаете? DST там всегда равен служебному адресу, что и определяет, что пакет есть PAUSE.

Чтаю здесь. Вот выдержка оттуда:

The destination address of the frame may be set to either the unique DA of the station to be paused, or to the globally assigned multicast address 01-80-C2-00-00-01 (hex). This multicast address has been reserved by the IEEE 802.3 standard for use in MAC Control PAUSE frames. It is also reserved in the IEEE 802.1D bridging standard as an address that will not be forward by bridges. This ensures the frame will not propagate beyond the local link segment.

Кроме того, не согласен, что dst_адресс =01-80-C2-00-00-01 определяет PAUSE пакет. Вот, что определяет (взято оттуда же):

The "Type" field of the PAUSE frame is set to 88-08 (hex) to indicate the frame is a MAC Control frame.
The MAC Control opcode field is set to 00-01 (hex) to indicate the type of MAC Control frame being used is a PAUSE frame.

Тормозить хосты в других сегментах (под сегментом я понимаю в данный момент соединение точка-точка между MAC-контроллерами - грубо говоря один прямой или кросс-кабель) нет никакого смысла - удаленный хост вполне себе может меняться с другими хостами, а не только с тем на котором затык и который высылает PAUSE. Также на маршруте может быть буферизация (например, в свичах) - тогда блокировка выглядит вообще вредной - не дает нормально пользоваться буферизацией. Поэтому пакет PAUSE именно имеет фиксированное значение dst адреса, и предназначен для приостановки передачи именно в непосредственно подсоединенном полнодуплексном сегменте (для полудуплекса там другие методы типа back pressure используются)

Я говорю не о p2p, а о некоторой локальной сети из хостов, обьединенных через свитч(и)- наиболее типичный случай для небольших фирм и офисов. Здесь
текущая конфигурация хостов без проблем отслеживается в таблице MAC адресов свитча. Блокировку порта свитча через пауз- пакет считаю неправильной и нереальной, т.к. хост-источник потока данных ничего не будет занать о такой блокировке и продолжит накачивать буфер свитча, пока тот не переполнится. Поэтому, единственно возможный вариант выровнять скорости приема-передачи- это Flow-Control непосредственно на источнике данных. Вывод- свитч должен тупо пересылать PAUSE пакеты по назначению. И никакой самодеятельности.

Вывод - адрес хоть и малтикастовый, но из зарезервированного диапазона, и если свич "правильный", то никуда PAUSE дальше не пойдет.

Каким поставить dst_адрес в PAUSE пакете- это дело хоста-приемника данных. Если он в состоянии определить MAC-адрес источника, который на него навалися, то ставим именно его адрес в поле назначения. Если же не можем определить откуда навал- ставим универсальный мультикастовый. В последнем случае будут заторможены все хосты данной локальной сети, поскольку свитч разошлет паузу им всем.

[VslavX]

Читаю здесь.

ИМХО, там какое-то народное творчество. "Не читайте до обеда советских газет" ©. Смотрим IEEE Std 802.3™-2008, Section 2, Annex 31B, называется MAC Control PAUSE operation (специально не поленился скачать редакцию 2008 года, до этого ковырялся в 2002):

31B.1 PAUSE description
The PAUSE operation is used to inhibit transmission of data frames for a specified period of time. A MAC Control client wishing to inhibit transmission of data frames from another station on the network generates a MA_CONTROL.request primitive specifying:
a) The globally assigned 48-bit multicast address 01-80-C2-00-00-01,
b) The PAUSE opcode,
c) A request_operand indicating the length of time for which it wishes to inhibit data frame transmission.
(See 31B.2.)

The PAUSE operation cannot be used to inhibit transmission of MAC Control frames. PAUSE frames shall only be sent by DTEs configured to the full duplex mode of operation. The globally assigned 48-bit multicast address 01-80-C2-00-00-01 has been reserved for use in MAC Control PAUSE frames for inhibiting transmission of data frames from a DTE in a full duplex mode IEEE 802.3 LAN. IEEE 802.1D-conformant bridges will not forward frames sent to this multicast destination address, regardless of the state of the bridge’s ports, or whether or not the bridge implements the MAC Control sublayer. To allow generic full duplex flow control, stations implementing the PAUSE operation shall instruct the MAC (e.g., through layer management) to enable reception of frames with destination address equal to
this multicast address.

Я говорю не о p2p, а о некоторой локальной сети из хостов, обьединенных через свитч(и)- наиболее типичный случай для

В случае если используется BASE-TX, то сеть на L2 именно и состоит из набора P2P.

хост-источник потока данных ничего не будет занать о такой блокировке и продолжит накачивать буфер свитча

"И это хорошо!" ©. А зачем хосту-источнику знать о блокировке приема хоста приемника, если источник как раз может чудно слать данные в буфер свича? Есть возможность - данные из хоста отправляем, ничего не ждем, а оборудование на маршруте само разберется. Я вот чудный гигабитный свичик SLM2008 прикупил - никак не могу определить сколько у него памяти на борту - по разным источникам от 4 до 32 Мегабайт. "Это жжжж - наспроста" © - имхо, Циско что-то знает, раз столько памяти в свич ставит.

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

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

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

Нет, не так - по стандарту PAUSE тут же в свиче и умирает:

The globally assigned 48-bit multicast address 01-80-C2-00-00-01 has been reserved for use in MAC Control
PAUSE frames for inhibiting transmission of data frames from a DTE in a full duplex mode IEEE 802.3
LAN. IEEE 802.1D-conformant bridges will not forward frames sent to this multicast destination address,

Upd: редакция стандарта 2002 говорит тоже самое. Возможно еще более старые стандарты допускали отправку индивидуального DA, но на сегодня это не так.

Upd2: просмотрел Ethernet MAC контроллеры для которых писал код (SAM7X, LPC17/23, MPC83xx, STM32F2xx) нигде не нашел в регистрах как задавать DA - везде PAUSE фреймы генерируются автоматически, с фиксированным в стандарте малтикастом. На прием аналогично - проверяется именно малтикаст. Так что - на упомянутых контроллерах фрейм PAUSE с уникальным DA это типа "закат солнца вручную" - только искусственно сформировать и отослать как обычный пакет.

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

Это вообще шедевр. У меня такой свич на следующий день на помойке был бы. Типа домашние смотрят с NAS-а по DLNA фильм, а я в той же домашней сетке устройство на микроконтроллере отлаживаю, как там затык - расступись море получите фриз вместо фильма?

[Aprox]

В случае если используется BASE-TX, то сеть на L2 именно и состоит из набора P2P.

Не совсем так. В одноранговых сетях peer-to-peer каждый хост должент выполнять административные функции и отслеживать общую конфигурацию сети. Например средства MS-сети, встроенные в Windows, так называемые "подключения". В принципе, пользоваться услугами такой сети, где все равны в правах, неправильно из соображений элементарной безопасности. В более-менее серьезных организациях не используется. Поэтому вы ошибаетесь насчет повсеместного p2p.

"И это хорошо!" ©. А зачем хосту-источнику знать о блокировке приема хоста приемника, если источник как раз может чудно слать данные в буфер свича? Есть возможность - данные из хоста отправляем, ничего не ждем, а оборудование на маршруте само разберется. Я вот чудный гигабитный свичик SLM2008 прикупил - никак не могу определить сколько у него памяти на борту - по разным источникам от 4 до 32 Мегабайт. "Это жжжж - наспроста" © - имхо, Циско что-то знает, раз столько памяти в свич ставит.

Вы снова ошибаетесь. Вот типичный пример. Есть некий источник данных, который может формировать UDP пакеты и отправлять их по гигабитному Ethernet каналу в сеть со скоростью примерно 800 mbps. В этой сети, имеется приемник этих UDP-пакетов, который может принимать и обрабатывать поток данных не быстрее, например 400 mbps. Хосты соединены через гигабитный свитч. Теперь прикиньте, за какое время переполнится 32 Мегабайт буфер вашего хваленого свитча, если торомозить порт свитча и не торомозить непосредственно источник данных? Правильный ответ- за 1 минуту.

Нет, не так - по стандарту PAUSE тут же в свиче и умирает:

Ничего личного, но криво читаете стандарты. Там говорится, что PAUSE умирает в bridge, но не в switch. Это сильно разные вещи. и для разных целей. Еще предлагаю подумать- откуда в свитчах на портах вдруг взялся MAC? Его там нет по определению. А раз нет, то и управления на уровне MAC устройства- тоже нет. Свитч воспринимает все входящие пакеты одинаково, включая пакеты FlowControl.

Upd2: просмотрел Ethernet MAC контроллеры для которых писал код (SAM7X, LPC17/23, MPC83xx, STM32F2xx) нигде не нашел в регистрах как задавать DA - везде PAUSE фреймы генерируются автоматически, с фиксированным в стандарте малтикастом. На прием аналогично - проверяется именно малтикаст. Так что - на упомянутых контроллерах фрейм PAUSE с уникальным DA это типа "закат солнца вручную" - только искусственно сформировать и отослать как обычный пакет.

Я занимаюсь отправкой UDP-пакетов в гигабитный Ethernet используя в качестве контроллера FPGA. Скорости формирования и отправки данных примерно такие, как я представил в живом примере выше. Эта задача решена только за счет того, что в PAUSE пакте проставляется конкретный MAC-адрес источника данных. И представьте, этот пакет прекрасно проходит через свитч и достигает именно источника!

[Костян]

Я занимаюсь отправкой UDP-пакетов в гигабитный Ethernet используя в качестве контроллера FPGA. Скорости формирования и отправки данных примерно такие, как я представил в живом примере выше. Эта задача решена только за счет того, что в PAUSE пакте проставляется конкретный MAC-адрес источника данных.

У меня к Вам практический вопрос. Нужно ли PHY конфигурировать на enable pause ?

[Aprox]

У меня к Вам практический вопрос. Нужно ли PHY конфигурировать на enable pause ?

Признаться, специально такой конфигурацией PHY не занимался. Использую PHY autonegotiation, которая происходит автоматически при вкл.питания. По его окончании всегда можно прочесть в регистрах PHY, на что способно данное подключение. У PHY-источника при autonegotiation по-моему всегда установлено enable flow control по умолчанию. Эту опцию можно изменить потом программно на disable. Но тогда, вслед за этим, придется также программно запускать и autonegotiation, чтобы дать знать приемнику на другой стороне канала связи- мол, не шли мне пауз-пакеты, я их все равно не понимаю.

Сами же пауз-пакеты формирует MAC. PHY же только их отправляет, ему до лампочки.