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

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

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

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

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

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

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

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

Наличи режима Flow Control, на сколько я помню можно оценить в режиме "автопереговоров". И кстаи он создовался именно для ограничения скоростип риёма данных от комутаторов в режиме Full duplex и поддерживается соответсвенно всеми комутаторами. А вот наличие его в конечных устройствах, потребителях данных весьма редко встречается, разработчики редко заморачиваются на счёт этого.

Совершенно верно. Во время автопереговоров трансиверы портов уточняют возможность друг друга управлять потоком с помощью пакета-паузы. Далее результат можно прочесть в соответствующих регистрах PHY.

Теперь и у меня возник вопрос - допустим имеются две машины (A и Б), соединенные через свитч. На свитч от машины A приходит пакет-пауза, как тогда должен поступить свитч - пробросить этот пакет-паузу до машины Б, или же приостановить трафик от машины Б (просто отбрасывать пакеты) ???

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

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

Со стороны свич<->B:
При приеме пакета определить, куда он направляется. Допустим, в А. Если буфер передачи свич->A у свича близок к заполнению, то передать в B пакет PAUSE. По освобождению буфера передать пакет PAUSE с нулевым таймером (разрешить передачу B->свич). Если место в буфере есть - положить туда пакет.

Со стороны свич<->A:
Если A прислал пакет PAUSE, прекратить передачу из буфера (а если состояния PAUSE нет, то передавать что есть в буфере). По окончанию таймера PAUSE (или по приему пакета PAUSE(0)) возобновить передачу из буфера в A.

Естественно, алгоритм одинаков на всех портах.

Все.

А MAC-адрес в пакете PAUSE не используется - ибо соединение у 100/1000/1G/10G - точка-точка.

Спасибо, теперь разобрался

Странно. Я вот читаю описание PAUSE пакета и вижу, что MAC адреса, и Dst, и Src, очень даже используются. Причем, Dst может указывать на конкретный хост в сети, который надо тормозить. Также Dst может быть равным 01-80-С2-00-00-01, что означает- тормозить все устройства в сегменте сети. В этой связи выглядит неубедительным ваше описание работы свитча. По-моему, ему нет никакой нужды реализовать какой-либо Flow-Control внтури себя, достаточно тупо пересылать PAUSE пакеты по назначению хостам. Или я что-то неправильно понял?

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


ЕМНИП, никуда PAUSE свичами не пересылается - а просто употребляется по назначению на принявшем его порту - только этот конкретный порт временно приостанавливает передачу. Другие порты банально могут быть полудуплексными - пакет PAUSE там просто не будет иметь смысла.

Вот выдержка из википедии (стандарты лень копать - они там неохватные):

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

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

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

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





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

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

Чтото не то Вы читаете. Надо бы курить непосредственно IEEE802.3, благо они открыто доступны.

Странный совет. Я представил именно смысловую выжимку из стандарта IEEE802.3.

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




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


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


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



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


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

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



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

И не было никогда. Так что господину Aprox'у настоятельно рекомендую таки курить IEEE802.3, а не что попало в этих интернетах.