Кадры паузы передаются на хост?

1269
user_ABCD

Недавно я видел форум Debian, на котором упоминались кадры паузы, которые должны отбрасываться уровнем MAC, а если нет, драйвер должен их отбрасывать. Это правда? Как хост фактически ограничивает обратный трафик, если он получил кадр паузы от коммутатора?

Я пытаюсь лучше понять управление потоком Ethernet. Если приведенное выше утверждение верно, что действительно означает передача на хост?

3

2 ответа на вопрос

3
David Schwartz

Есть три способа управления потоком:

  1. Если вы перегружены, вы бросаете данные на пол.
  2. Если вы не можете предоставить услугу для запроса из более высокого уровня, как правило, потому что ваша локальная очередь заполнена, вы возвращаете ошибку в этот более высокий уровень.
  3. Вы заблаговременно уведомляете верхние слои о том, что они должны замедлиться.

На уровне Ethernet метод 3 поддерживается через кадры паузы. Часто верхние уровни не поддерживают метод 3, но вместо этого поддерживают метод 2. Если под слоем есть слой под ним, который поддерживает метод 3, но слой над ним поддерживает только метод 2, он может временно остановить передачу данных на нижние уровни, вызывая метод 2, чтобы применить к более высоким слоям.

Или, более конкретно, когда вы получаете кадр паузы, вы останавливаете механизм отправки и устанавливаете таймер для перезапуска механизма отправки в соответствующее время. Пока механизм отправки остановлен, ваши локальные очереди будут заполняться данными из более высоких уровней. Если они заполняются, вы возвращаете «занятые» ошибки на более высокие уровни, и они обрабатывают это, однако, уместно.

Так как же кадр паузы отправляется вверх по стеку и, в свою очередь, NIC замедляет передачу трафика? Контроллеры Ethernet поддерживают управление потоком, но я не могу определить, почему трафик не «останавливается». user_ABCD 8 лет назад 0
Кадр паузы не отправляется в стек. Нижний уровень стека просто прекращает чтение кадров из очереди. Когда очередь заполняется, более высокие уровни обнаруживают это, когда их функции «добавить пакет в очередь» не выполняются. (Прочитайте последний абзац.) David Schwartz 8 лет назад 4
Я совершенно новичок во всем этом, но если я вас правильно понимаю, что заставляет меня перестать читать кадры из очереди? Используя ethtool, я вижу, что получаю кадры паузы от коммутатора. Но мое приложение udp никогда не замедляется в отношении бит / с. user_ABCD 8 лет назад 0
Я не знаю специфику вашего UDP-приложения (и платформы), но обычно это тот механизм, который будет обрабатывать случай, когда не было кадров паузы. Поскольку вы также можете перегружать нелокальные каналы, не относящиеся к Ethernet, вы не можете полагаться на кадры паузы в качестве времени передачи UDP, и обычно нет смысла создавать два механизма. Если ваша платформа действительно распространяет информацию вплоть до пользовательского пространства, вы, как правило, обнаруживаете ее, потому что `sendto` на неблокирующем UDP-сокете будет возвращать указание" будет заблокировано ". David Schwartz 8 лет назад 1
Хммм. Я почти уверен, что понимаю вас. Есть ли хороший способ определить, обработал ли я хотя бы кадры паузы? В настоящее время я знаю две вещи: я действительно получаю кадры паузы (ethtool) и пропускная способность (wireshark), кажется, никогда не меняется. Почти как более высокие уровни никогда ничего не делают, когда я получаю кадры паузы. user_ABCD 8 лет назад 0
3
Spiff

До сих пор управление потоком Ethernet было неудачным экспериментом, поскольку оно часто вызывает проблемы с блокировкой заголовка. Коммутаторы не должны отправлять кадры паузы хостам. Я полагаю, что коммутаторы Cisco не могут быть настроены для отправки кадров паузы; включение управления потоком Ethernet на коммутаторе Cisco просто заставляет его соблюдать кадры паузы, которые он получает. Хозяева должны игнорировать полученные кадры паузы.

Если коммутатор не может управлять передачей, он должен уронить кадр. Более высокие уровни, прежде всего TCP, используют пропущенные кадры, чтобы знать, когда возникла перегрузка и когда нужно отступить. Отказ от отбрасывания кадров приводит к сбою TCP Congestion Control, что обычно приводит к буферизации .

Почему коммутатор не должен отправлять кадры паузы? У меня есть сетевой переключатель, который отправляет их на хосты. Как один хост говорит другому хосту замедляться? user_ABCD 8 лет назад 0
@user_ABCD Подробнее о [блокировке заголовка строки] (https://en.wikipedia.org/wiki/Head-of-line_blocking). Представьте себе коммутатор, подключенный к серверу GigE, клиенту GigE и клиенту со скоростью 100 Мбит / с, и оба клиента загружаются с сервера. Входной буфер коммутатора с сервера может заполниться, поскольку пакеты не могут быть отправлены клиенту со скоростью 100 Мбит / с достаточно быстро. Затем коммутатор отправляет кадр паузы на сервер, причиняя вред клиенту GigE. Оказывается, лучше справляться с перегрузкой, просто отбрасывая кадры на уровне Ethernet, что позволяет верхним уровням определять, когда нужно замедляться. Spiff 8 лет назад 0
Это на самом деле не отвечает на то, что происходит, когда кадры паузы _are_ используются ... grawity 8 лет назад 0
@ Spiff, вы предлагаете, чтобы после заполнения входного буфера коммутатора он отправлял кадры паузы на все порты с включенным управлением потоком? Замедляет работу всей сети? user_ABCD 8 лет назад 0
@user_ABCD Нет, просто порт сервера в моем примере. Если у коммутатора есть отдельные входные буферы для каждого порта на каждом порту, а входной буфер * на порту сервера * заполнен из-за медленного клиента, коммутатор может отправить кадр паузы * только на сервер *, который блокирует сервер от обслуживания других клиентов, таких как быстрый клиент. Spiff 8 лет назад 0
@Spiff, это помогает куче. Моя таблица данных коммутатора говорит, что память буфера пакетов динамически распределяется между используемыми портами. Это означает, что они не имеют входных буферов для каждого порта? user_ABCD 8 лет назад 0

Похожие вопросы