Не совсем так. В одноранговых сетях 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".