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

Делаю девайс, который, если в общих чертах, принимает пакеты 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, а не что попало в этих интернетах.

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

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

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

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

Читал-читал, но на этом перле уж не сдержался.
Уважаемый! Вы хоть немного теории почитайте для начала, ну нельзя же так, только по своим представлениям о мире судить. Эдак можно и до земли на трех китах дойти!

Мда, "смешались в кучу люди, кони" (с).
Есть такая вещь - OSI - Open Systems Interconnection. Она описывает уровни сетевого взаимодействия, классической считается 7-уровневая модель. Так вот, обсуждаемый в данном топике Flow Control относится к уровню L2 (канальный, Data Link Layer). А все что Вы написали - администрирование, конфигурирование и прочее - как минимум парой-тройкой уровней модели выше и к топику имеет очень и очень слабое отношение.

Повторюсь - p2p на канальном уровне (L2). Если используется Ethernet на витых парах, то порт каждого хоста на канальном уровне общается непосредственно с портом другого хоста или свича. И каждое такое соединение на канальном уровне - точка-точка, отдельный сетевой физический сегмент.


ИМХО, это не типичный пример, а сложности FPGA-шников при реализации нормального надежного транспортного протокола типа TCP.


Оставляя в стороне типичность примера и соответствие выбранной топологии задаче, а кто Вам сказал что источник не будет тормозиться? Тормозится он будет - но не конечным приемником, а по переполнению буфера в свиче. То есть - когда буфер в свиче (а не в приемнике данных) начинает переполняться - свич сам выдаст источнику PAUSE.


Нет, вот именно ethernet switch на витых парах и является bridge - поскольку он соединяет физически отдельные сетевые сегменты на уровне L2. То что эти сегменты используют физику одного стандарта (а не разных) не имеет ровно никакого значения - все равно это bridge.


Он проходит и достигает, поскольку Вы нарушили стандарт и засунули в пакет не требуемое фиксированное малтикастовое значение DA, а индивидуальное. А ведь вполне может попасться такой свич который еще и на управляющее поле пакета смотреть будет - от тогда PAUSE может и не дойти. И Вы хотите сказать, что если указать фиксированный DA в PAUSE, то возникают проблемы? ИМХО, тогда это не очень хорошее оборудование (свич).

Итого, для меня результаты дискуссии такие:

1. Стандарт четко описывает чего в PAUSE посылается, и как PAUSE на уровне L2 коммутируется.
2. Распространенные микроконтроллеры не имеют средств задания индивидуального DA в отсылаемом PAUSE и не понимают индивидуальный DA в принимаемом PAUSE.
3. Просто здравый смысл (пример с NAS, DLNA-телевизором и тестовым девайсом)

Дальше, в-общем-то, обсуждать нечего.

Когда я реализовывал свой сетевой стек, вопрос Flow Control на уровне L2 обдумывал тщательно, в итоге его не использую вообще. Все функции FC возложены на транспортный уровень - в моем случае TCP. Правильный выбор размера окна решает(_в общем случае_, а не только при использовании ethernet) проблему переполнения и прекрасно масштабируется, например HTTP-сервер на 8 сокетов, живет на 4К буферной памяти с окнами по 512 байт на LPC23, а искази-таргет выжимает по TCP 70Мбайт/сек с мегабайтным окном на MPC8347.

У Вас в FPGA нет TCP (по крайней мере такого же быстрого как аппаратный UDP), отсюда и желание использовать Flow Control на нижних уровнях сетевой модели. Я думаю, если сделаете по стандарту (фиксируете DA в PAUSE) и возьмете нормальный свич, то ситуация хуже не станет.

Вы правы. У нас сильно разные практические задачи. Найти общий язык и доказать что-либо вряд-ли получится.

Даже пробовать, и потом плясать с бубном вокруг зависшей системы,- я не стану. У меня прекрасно работает, как я написал- с DA, равным MAC адресу источника данных. И обычная сетевая карта с включенной опцией FlowControl в хосте-источнике прекрасно понимает PAUSE-пакеты, которые пришли к ней через свитч. Несмотря на то, что адрес назначения стоит не мультикастовый. Узнает по значению поля FrameType и коду операции FlowControl.

Честно говоря, я не понимаю о чем мы спорим. Я представил Вам живой работающий пример высокоскоростной передачи данных ( до 860 mbps). Все работает на jumbo-пакетах в протоколе UDP с притормаживанием на MAC уровне. В любимом вами TCP такой поизводительности достичь невозможно, Да и проблема FlowControl в TCP вообще не актуальна. TCP было отвергнуто с самого начала. А FPGA было выбрано потому, что софтовый стек на микроконтроллере не обеспечивает требуемую производительность на гигабитном канале Ethernet. Не о чем спорить.

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

ИМХО, конфигурировать PHY нужно в той части, в которой оно сообщает своему Link Partner о поддержке Flow Control. Я понимаю это так, что самому PHY принимаемые-передаваемые фреймы PAUSE безразличны и в самом PHY ни на что не влияют. Но при установлении линка два PHY между собой проводят negotiations - меняются между собой специальными фреймами (которые на MAC не транслируются), и вот там передается информация о поддержке Flow Control MAC-ом каждой стороны. Поскольку PHY о возможностях имеющегося на его стороне MAC ничего не знает, то обычно внутри PHY имеется регистр, куда софт до разрешения линка и проведения negotiations записывает информацию о том как имеющийся в наличии MAC и его драйвер будут поддерживать PAUSE. Потом линк разрешается, PHY проводят между собой negotiations и софт на удаленном хосте может прочитать из своего PHY результаты "переговоров" и узнать, будет ли наш MAC передавать и принимать PAUSE-фреймы.

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

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

Нет, надо смотреть даташит на конкретный PHY чип. Например, MV88E1111 конфигурируется внешними ножками, что именно декларировать при negotiation. А у KSZ8031 - по дефолту после сброса стоит "No PAUSE".