Re: lug-bg: Драйвъри за мрежови платки с поддръжка на MTU>1500
- Subject: Re: lug-bg: Драйвъри за мрежови платки с поддръжка на MTU>1500
- From: George Danchev <danchev@xxxxxxxxx>
- Date: Fri, 17 Dec 2004 03:09:45 +0200
On Thursday 16 December 2004 18:53, Vesselin Kolev wrote:
> Peter Pentchev wrote:
> >На мен ми се струва, че по принцип такава е идеята... В смисъл:
> >
> >1. Според първоначалните стандартите за Ethernet, MTU на Ethernet iface е
> > 1500, точка.
>
> Доста невярно. При IPv6 изобщо не е 1500. Ето ти една конфигурация от
> Juniper интерфейс забоден в ethernet среда, в която всички участници са
> с IPv6 (иде реч за мрежа в CERN, но подобни има и по университети в GEANT):
Ами според мен не би трябвало да има значение дали е третия слой е ipv4 или
ipv6 след като втория слой ethernet прави фрейма.
> interfaces {
> ge-1/0/0 {
> enable;
> vlan-tagging;
> mtu 9192;
> unit 570 {
> vlan-id 570;
> family inet6 {
> address fec0:2::2/64;
> }
> }
> }
> ge-1/2/0 {
> family inet6 {
> address fec0:3::2/64;
> }
> }
> }
> }
>
> Обърни внимание на параметъра MTU. Това е също ethernet.
>
> Ето ти и един Cisco:
>
> interface GigabitEthernet4/2
> description ----> r05gva
> mtu 9216
> no ip address
> logging event link-status
> load-interval 30
> mls qos trust dscp
> switchport
> switchport trunk encapsulation dot1q
> switchport trunk allowed vlan 1,7,570
> switchport mode trunk
> no cdp enable
>
>
> Ето ти и един Linux 2.6 (Fedora Core 3):
>
> [root@intruder root]# echo "4096 87380 128388607" >
> /proc/sys/net/ipv4/tcp_rmem [root@intruder root]# echo "4096 65530
> 128388607" > /proc/sys/net/ipv4/tcp_wmem [root@intruder root]# echo
> 128388607 > /proc/sys/net/core/wmem_max [root@intruder root]# echo
> 128388607 > /proc/sys/net/core/rmem_max [root@intruder root]# ip addr add
> fec0:3::3/64 dev eth0
> [root@intruder root]# ip -f inet6 route add fec0:1::/64 via fec0:3::2
> [root@intruder root]# ifconfig eth0 mtu 9000
> [root@intruder root]# ifconfig eth0 txqueuelen 10000
да всичките тези са 10000 етернет адаптори и защо само техните драйвери
позволяват това може би ще се разбере ако се разгледа например
drivers/net/e1000/ в сорса на ядрото, което ми се видя не много тривиално на
диагонал ;-)
> Не се използват jumbo frames. Картите са Intel базирани.
ами всеки payload > 1500 е jumbo frame.
> Не виждам и това какво общо има с темата VLAN. И не виждам никакво
> нарушение с Ethernet технологията. Според мен нещо бъркаш IEEE
> стандартите един с друг, но това е друга тема, далеч от 802.1q... Да не
> задълбаваме.
>
> >2. С въвеждането на VLAN's се появява едно именно "скрито" MTO от 1504,
> > което важи *само* за пакети с VLAN header. Все пак НЕ МОЖЕШ да
> > изпратиш нормален Ethernet пакет без VLAN header, който пакет да е
> > по-голям от 1500 байта, защото виж точка 1.
>
> Също невярно. VLAN стандарта не въвежда никакво MTU (нито скрито, нито
> явно). Прочети документа по стандарта и ще видиш, че 802.1q въвежда ново
> поле в ethernet хедъра: VLAN Frame Header = Frame Header + 4 и не отдава
> значение на стойността на MTU. Имаш 4 байта за VLAN-ID. При наличие на
> бриджиращи рутери с тунели помежду им и т.н. може да се дефинира и
> по-малък Frame Header и пак да има VLAN (макар това малко да усложнява
> технологията и да товари в фрагментиране ако на краищата има големи MTU
> стойности).
всъщност да ifconfig ще покаже стойността на payload-a, а не и допълнителните
полета. От 68 до 12000 байта за payload би трябвало да е окай (над 12к става
супер неефективно за среда като етернет). 1500 mtu (говоря за payload-а) е
препоръчително за съвместимост (предполагам, че по-високите стойности са
дошли като нова мода от гигабитовия етер). Отделно към тези 1500 имаме 14
байта за ethernet хедъра, 4 байта за 802.1q VLAN тагове и 4 байта за CRC
контролни суми. Не всички (цискнята, джунипер, юникси) използват всичко от
това и може би се получава малко объркване.
> >3. С въвеждането на GigE се появяват jumbo frames, които могат да бъдат
> >
> > > 1500, но *само* върху GigE интерфейси и май само когато картите са
> >
> > се договорили за това. Не съм сигурен дали изобщо има GigE карти,
> > които да са съгласни да пускат jumbo frames върху 100Mbit интерфейси.
> > Причината е елементарна: може на този интерфейс да има "нормална"
> > Ethernet карта, която си знае стандарта и просто не може да преглътне
> > фрейм, по-голям от 1500 байта.
всъщност това мисля, че зависи от драйвера който конструира payload-a (data
частта) + етернет хедъра + евентуално vlan tag + евентуално crc суми ако има.
Т.е. според мен не би трябвало да зависи от изпълнението на адаптора, е ако
не е някакво хардуерно извръщение де с вграден целио ОСИ модел на ИСО
(шегувам се ;-)
> ... излез от IPv4!!!
>
> Освен това аз питах за 100 Mbps карти, които могат да поддържат MTU
> 1504. Мисля, че тикаме разговора в малко по-друга посока...
За линукс ядрото, това което си мисля (а може и да греша де) е, че всички
драйвери на 100 Mbps адаптори включват индиректно include/linux/if_ether.h
(през include/linux/etherdevice.h), където са дефинирани твърдо
ETH_DATA_LEN 1500 (това е payload-a, data частта)
ETH_FRAME_LEN 1514 (горното + 14 байта за ethernet хедъра)
Опитай да промениш payload-a на ETH_DATA_LEN 1504 и ребуилд
(пък що не и на 4000 9000 12000, само, че ще трябва да гледаш етернет фрейма
да е точно с 14 байта по-голям от дейта частта, че може да настане веселба в
етера ;-) не съм сигурен обаче дали user-space utils правят някъф чекинг
когато подаваш мту параметъра на драйвера, всъщност не би трябвало, просто
требе да случат какво ще им върне ядрото като отговор.
Всъщност каква е причината на това упражнение ?
--
pub 4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================
|