|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 07 Feb 2007 12:58:53
To : Alex Bakhtin
Subject : Re: Jumbo frames and fxp
--------------------------------------------------------------------------------
>>> Alex Bakhtin wrote:
AM>> Hевалидный фрейм - это когда у него контрольная сумма неверная, или,
AM>> например, нецелое число октетов. Такие фреймы дропаются как искаженные при
AM>> передаче.
AM>> MTU я понимаю как максимальный размер, который способны принять
AM>> получатели.
AB> Вот именно. И мы, как получатель, не можем принять фрейм размером
AB> больше MTU. Что-то путаница у тебя какая-то в голове:)
AM>> Его назначение - не передавать фреймы, которые получатель не сможет
AM>> принять. Я
AB> Вот пусть и не передают фреймы, которые мы принять не можем.
Я вот одного не могу здесь понять. Фрейм-то уже принят. Он целый
(контрольная сумма сошлась). Почему мы его считаем невалидным только
потому, что он превышает наше MTU? Почему форсирована связь MTU
(который определяется _политикой_ применения интерфейса) и MRU
(который определяется свойствами канала и физического интерфейса)?
Хочу услышать чёткое обоснование, зачем нужна такая связь, какие
проблемы будут, если она будет нарушена. Пока что я вижу
отрицательные последствия только политики принудительного равенства
MRU и MTU, но не наоборот. (См. также абзацем ниже)
AM>> Я не вижу оснований считать принятый фрейм невалидным только потому, что
AM>> он превышает MTU.
AB> В rx ring есть положены кусочки памяти (я условно, на надо меня сразу
AB> пинать даташитами на контроллеры) размером в MTU. В какое место памяти
AB> предлагаешь пихать карте лишние байты? MTU как раз и определяет - какого
AB> размера буфера будут выделены карте под rx ring. А пакет, не лезущий в
AB> буфер - плохой, негодный пакет.
Это изначально кривой случай, случай как раз форсированного,
насильственного приравнивания MRU к MTU. То есть тут сначала
вводится тождество, а потом показываются последствия, что будет,
если придёт больший пакет в этих уже заведомо искажённых условиях.
Далее, эта ситуация специфична для jumbo frames (кто-то назначит MTU
9000 - да, надо быть готовым принимать и такие кадры, а иначе вряд
ли надо специально готовиться), но вряд ли кому-то всерьёз придёт в
голову устроить запрет приёма стандартных 1500-байтных кадров...
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
