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-адрес источника, который на него навалися, то ставим именно его адрес в поле назначения. Если же не можем определить откуда навал- ставим универсальный мультикастовый. В последнем случае будут заторможены все хосты данной локальной сети, поскольку свитч разошлет паузу им всем.