Jump to content

    
Sign in to follow this  
Koluchiy

Ethernet: насколько распространена поддержка Flow control?

Recommended Posts

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

 

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

 

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

 

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

 

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

Прежде всего интересуют различные свичи и прочее "магистральное" оборудование.

 

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Наличи режима Flow Control, на сколько я помню можно оценить в режиме "автопереговоров".

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

 

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

Share this post


Link to post
Share on other sites
должен поступить свитч - пробросить этот пакет-паузу до машины Б, или же приостановить трафик от машины Б (просто отбрасывать пакеты) ???

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

 

Share this post


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

 

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

 

Со стороны свич<->B:

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

 

Со стороны свич<->A:

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

 

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

 

Все.

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites
Причем, Dst может указывать на конкретный хост в сети, который надо тормозить.

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

 

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

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

 

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

Pause frame

 

The overwhelmed network element can send a PAUSE frame, which halts the transmission of the sender for a specified period of time. Media Access Control (MAC) frames to carry the PAUSE commands using Control opcode 0x0001 (hexadecimal). Only stations configured for full-duplex operation may send PAUSE frames. When a station wishes to pause the other end of a link, it sends a MAC Control frame to the 48-bit destination reserved multicast address of 01-80-C2-00-00-01. The use of a well-known address makes it unnecessary for a station to discover and store the address of the station at the other end of the link.

 

Another advantage of using this multicast address arises from the use of flow control between network switches. The particular multicast address used is selected from a range of address which have been reserved by the IEEE 802.1D standard which specifies the operation of switches used for bridging. Normally, a frame with a multicast destination sent to a switch will be forwarded out all other ports of the switch. However, this range of multicast address is special and will not be forwarded by an 802.1D-compliant switch. Instead, frames sent to this range are understood to be frames meant to be acted upon only within the switch.

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

Share this post


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

 

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

Share this post


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

Share this post


Link to post
Share on other sites
Чтото не то Вы читаете. Надо бы курить непосредственно IEEE802.3, благо они открыто доступны.

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

 

Share this post


Link to post
Share on other sites
Читаю здесь.

ИМХО, там какое-то народное творчество. "Не читайте до обеда советских газет" ©. Смотрим 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 фильм, а я в той же домашней сетке устройство на микроконтроллере отлаживаю, как там затык - расступись море получите фриз вместо фильма?

 

Share this post


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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this