|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Alex Mogilnikov 2:5054/70 27 Jan 2007 01:35:06
To : Alex Bakhtin
Subject : Jumbo frames and fxp
--------------------------------------------------------------------------------
25 Jan 07 16:40, Alex Bakhtin писал Alex Mogilnikov:
AM>> MTU я понимаю как максимальный размер, который способны
AM>> принять получатели.
AB> Вот именно. И мы, как получатель, не можем принять фрейм
AB> размером больше MTU.
Почему это? Кто сказал, что у всех получателей в сети способности
одинаковые?
AM>> Его назначение - не передавать фреймы, которые получатель не
AM>> сможет принять. Я
AB> Вот пусть и не передают фреймы, которые мы принять не можем.
Вот и я об этом - проверка должна выполняться на стороне отправителя.
AM>> не прав? А если так, то это не имеет никакого отношения к уже
AM>> принятому фрейму.
AB> Что значит "к принятому"
Цитирую /usr/src/sys/net/if_ethersubr.c:
==================================
/*
* Process a received Ethernet packet; the packet is in the
* mbuf chain m with the ethernet header at the front.
*/
static void
ether_input(struct ifnet *ifp, struct mbuf *m)
==================================
Что здесь означает "received"? Это значит, что электрический сигнал в
проводах преобразован в набор лежащих в памяти байтов.
AM>> Я не вижу оснований считать принятый фрейм невалидным только
AM>> потому, что он превышает MTU.
AB> В rx ring есть положены кусочки памяти (я условно, на надо меня
AB> сразу пинать даташитами на контроллеры) размером в MTU. В какое место
AB> памяти предлагаешь пихать карте лишние байты? MTU как раз и определяет
AB> - какого размера буфера будут выделены карте под rx ring. А пакет, не
AB> лезущий в буфер - плохой, негодный пакет.
Что же в таком случае получает на вход ether_input? Это во-первых.
Во-вторых, я бы еще понял, если бы такое отбрасывание производилось
драйвером физического устройства (конкретного сетевого адаптера), который,
действительно, отвечает за складывание принимаемых байтов в буфер ограниченного
размера (эту проверку, кстати, и так делают современные контроллеры). Hо вот для
них как раз эта проверка не выполняется, зато она выполняется например для
всяких vlan, которые сами никаким реальным приемом и складыванием байтов в буфер
не занимаются, а получают уже принятый и сложенный в буфер фрейм от
ассоциированного с ним физического интерфейса. Где же логика?
Всего наилучшего, [Team PCAD 2000]
Алексей М.
... Программисты и программистки! Выше флаг промежуточного переноса!
---
* Origin: === Сисоп спит - почта идет === (2:5054/70)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
