[ne-vlezay80]

Я сегодня случайно обнаружил, что после запуска гипервайзера не проходят большие пакеты. В iperf3 такая хрень:

ne-vlezay80@ne-vlezay80:~$ iperf3 -c 10.243.0.253
Connecting to host 10.243.0.253, port 5201
[  4] local 10.247.1.20 port 42916 connected to 10.243.0.253 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   175 KBytes  1.43 Mbits/sec    0   8.74 KBytes       
[  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    0   8.74 KBytes       
[  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   8.74 KBytes       
[  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   8.74 KBytes       
[  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   8.74 KBytes       
[  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   8.74 KBytes       
[  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   8.74 KBytes       
[  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   8.74 KBytes       
^C[  4]   8.00-8.43   sec  0.00 Bytes  0.00 bits/sec    0   8.74 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-8.43   sec   175 KBytes   170 Kbits/sec    0             sender
[  4]   0.00-8.43   sec  0.00 Bytes  0.00 bits/sec                  receiver
iperf3: interrupt - the client has terminated
ne-vlezay80@ne-vlezay80:~$ iperf3 -c 10.243.0.253
^C- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
Ошибка сегментирования

 

Потом в логах ядра:

[  135.609457] iperf3[3151]: segfault at 20 ip 00007f4482a77c7e sp 00007fffebb10df0 error 4 in libiperf.so.0.0.0[7f4482a6a000+1c000]
[  139.048338] iperf3[3154]: segfault at 20 ip 00007f56abefdc7e sp 00007ffd39c1ae40 error 4 in libiperf.so.0.0.0[7f56abef0000+1c000]
[  156.845542] ------------[ cut here ]------------
[  156.845562] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:272 dev_watchdog+0x210/0x220
[  156.845565] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
[  156.845572] Modules linked in: vhost_net vhost macvtap macvlan af_packet tun ebt_ip ebt_ip6 ebt_vlan ebtable_filter ebtables x_tables dummy nbd bridge 8021q garp mrp stp llc ata_generic pata_acpi snd_hda_codec_realtek snd_hda_codec_generic snd_usb_audio snd_usbmidi_lib uvcvideo snd_rawmidi snd_seq_device videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media kvm_amd kvm irqbypass nouveau snd_hda_intel snd_hda_codec snd_pcsp snd_hda_core snd_hwdep snd_pcm snd_timer snd r8169 soundcore ttm mii wmi pata_atiixp tpm_infineon ohci_pci ohci_hcd acpi_cpufreq tpm_tis tpm fuse ipv6 unix
[  156.845604] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.1 #1
[  156.845606] Hardware name: MSI MS-7715/870-C45(FX) V2 (MS-7715)  , BIOS V3.1 04/16/2012
[  156.845607]  0000000000000000 ffff88012b003d98 ffffffff81344f08 ffff88012b003de8
[  156.845612]  0000000000000000 ffff88012b003dd8 ffffffff8105a8ec 0000011000000005
[  156.845615]  0000000000000000 ffff8800cb8c2000 0000000000000000 0000000000000001
[  156.845619] Call Trace:
[  156.845620]  <IRQ>  [<ffffffff81344f08>] dump_stack+0x4d/0x65
[  156.845628]  [<ffffffff8105a8ec>] __warn+0xcc/0xf0
[  156.845631]  [<ffffffff8105a95a>] warn_slowpath_fmt+0x4a/0x50
[  156.845634]  [<ffffffff810715ae>] ? __queue_work+0x12e/0x400
[  156.845636]  [<ffffffff81607a30>] dev_watchdog+0x210/0x220
[  156.845638]  [<ffffffff81607820>] ? dev_deactivate_queue.constprop.32+0x60/0x60
[  156.845643]  [<ffffffff810b3c60>] call_timer_fn+0x30/0x130
[  156.845646]  [<ffffffff81607820>] ? dev_deactivate_queue.constprop.32+0x60/0x60
[  156.845648]  [<ffffffff810b4357>] run_timer_softirq+0x1f7/0x2a0
[  156.845650]  [<ffffffff8105fe18>] __do_softirq+0xf8/0x280
[  156.845652]  [<ffffffff810600c3>] irq_exit+0x83/0x90
[  156.845657]  [<ffffffff8101e48f>] do_IRQ+0x4f/0xd0
[  156.845661]  [<ffffffff81759fbf>] common_interrupt+0x7f/0x7f
[  156.845662]  <EOI>  [<ffffffff81025e96>] ? default_idle+0x16/0xd0
[  156.845666]  [<ffffffff81025f84>] amd_e400_idle+0x34/0xf0
[  156.845668]  [<ffffffff8102667a>] arch_cpu_idle+0xa/0x10
[  156.845670]  [<ffffffff81094520>] default_idle_call+0x30/0x40
[  156.845671]  [<ffffffff810947f5>] cpu_startup_entry+0x2c5/0x350
[  156.845673]  [<ffffffff81753902>] rest_init+0x72/0x80
[  156.845676]  [<ffffffff81d3ee78>] start_kernel+0x3e2/0x3ef
[  156.845678]  [<ffffffff81d3e434>] x86_64_start_reservations+0x2f/0x31
[  156.845682]  [<ffffffff81d3e520>] x86_64_start_kernel+0xea/0xed
[  156.845685] ---[ end trace 9600325ec049f29e ]---
[  156.855762] r8169 0000:02:00.0 eth0: link up

Ещё вот ping:

[br]

Ping контейнера на виртуалке во время сбоя:

ne-vlezay80@ne-vlezay80:~$ ping 10.243.0.253
PING 10.243.0.253 (10.243.0.253) 56(84) bytes of data.
From 10.247.1.1 icmp_seq=1 Destination Host Unreachable
From 10.247.1.1 icmp_seq=2 Destination Host Unreachable
From 10.247.1.1 icmp_seq=3 Destination Host Unreachable
From 10.247.1.1 icmp_seq=4 Destination Host Unreachable
From 10.247.1.1 icmp_seq=5 Destination Host Unreachable
From 10.247.1.1 icmp_seq=6 Destination Host Unreachable
From 10.247.1.1 icmp_seq=7 Destination Host Unreachable
From 10.247.1.1 icmp_seq=8 Destination Host Unreachable
From 10.247.1.1 icmp_seq=9 Destination Host Unreachable
From 10.247.1.1 icmp_seq=10 Destination Host Unreachable
64 bytes from 10.243.0.253: icmp_seq=11 ttl=61 time=1460 ms
64 bytes from 10.243.0.253: icmp_seq=12 ttl=61 time=461 ms
64 bytes from 10.243.0.253: icmp_seq=13 ttl=61 time=0.486 ms
64 bytes from 10.243.0.253: icmp_seq=14 ttl=61 time=0.313 ms
64 bytes from 10.243.0.253: icmp_seq=15 ttl=61 time=0.436 ms
64 bytes from 10.243.0.253: icmp_seq=16 ttl=61 time=0.427 ms
64 bytes from 10.243.0.253: icmp_seq=17 ttl=61 time=0.390 ms
64 bytes from 10.243.0.253: icmp_seq=18 ttl=61 time=0.369 ms
64 bytes from 10.243.0.253: icmp_seq=19 ttl=61 time=0.365 ms
64 bytes from 10.243.0.253: icmp_seq=20 ttl=61 time=0.351 ms
^C
--- 10.243.0.253 ping statistics ---
20 packets transmitted, 10 received, +10 errors, 50% packet loss, time 19006ms
rtt min/avg/max/mdev = 0.313/192.564/1460.794/444.554 ms, pipe 3

Сам сбой появляется только после загрузки хоста.

[br]

ifconfig:

root@ne-vlezay80:/home/ne-vlezay80# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 8c:89:a5:9d:fd:19  
         inet addr:10.247.1.20  Bcast:10.247.1.255  Mask:255.255.255.0
         inet6 addr: fe80::8e89:a5ff:fe9d:fd19/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1
         RX packets:625735 errors:0 dropped:0 overruns:0 frame:0
         TX packets:625544 errors:0 dropped:47 overruns:0 carrier:0
         collisions:0 txqueuelen:1000 
         RX bytes:4111173820 (3.8 GiB)  TX bytes:4112784642 (3.8 GiB)

[br]

Модуль ядра: r8169

[rm_]

и что вы хотите от участников форума?)

чтоб кто-нибудь резко подорвался зарыться в исходники ядра и починил для вас https://bugzilla.kernel.org/show_bug.cgi?id=99521 (а также https://bugzilla.kernel.org/show_bug.cgi?id=9882 где те же симптомы на этой железке тянутся с 2008 года)?:)

[ne-vlezay80]

и что вы хотите от участников форума?)

чтоб кто-нибудь резко подорвался зарыться в исходники ядра и починил для вас https://bugzilla.kernel.org/show_bug.cgi?id=99521 (а также https://bugzilla.kernel.org/show_bug.cgi?id=9882 где те же симптомы на этой железке тянутся с 2008 года)?:)

Странно, почему его до сих пор не исправили?

[myth]

Возможно, что никому оно особо не надо.

[Ivan_83]

Экономика проста.

Вот у меня рылотек тоже хз как с джамбой работает в домашнем компе (да и везде где он есть).

Чтобы это пофиксть нужна документация на чип и куча времени чтобы сравнить имеющийся драйвер с документацией.

С одной стороны мне эта джамба не сильно то и нужна дома, с другой даже если была бы нужна то скорее всего не только она а что нить ещё вкусное и я бы лучше взял интел.

(на е350 домашний сервак упирался процом в рылотек отдавая по самбе файлы, проблему решил i210, кардинально, сейчас там 5350 от амд, он в рылотек процом не упирается, у него производительности с запасом)

[rm_]

Возможно, что никому оно особо не надо.

Ну точнее среди тех кому это надо, никто не знает как починить.

[myth]

Это же домашнее железо... К чему там jumbo?

[ne-vlezay80]

Это же домашнее железо... К чему там jumbo?

К тому, чтобы полноценно vxlan'ы гонять, а также c этим играться!

 

Я заметил, сеть на qemu без JF работала на скорость 2,4Gbps. После внедрения JF скорость стала: 6.8Gbps в сигменте. На сколько выросла скорость работы сети в qemu?

[rm_]

полноценно vxlan'ы гонять

А вам точно для этого нужны JF на полные 9К?

Попробуйте 4082 и ниже (или если просто чтоб "пролазило" вместе со всякими тегами и инкапсуляциями, вообще в районе 2К).

Острота проблемы с уменьшением размера JF падает стремительным домкратом возможно вплоть до пропадания.

 

ifconfig ethX mtu 4082 это эмпирически вычисленное значение равное тому, что получается в винде если выбрать в драйверах "Jumbo Frames: 4K"

И заодно пакет целиком влазит в одну страницу памяти, скорее всего поэтому драйверу/железке и сильно проще.

 

Ещё одно "знаменательное" число - 7154, это "7K" виндовых дров. Две страницы памяти с запасом.

Кстати многие старые версии чипов реалтек и не дают выставить больше этих 4K/7K (зависит от чипа).

Edited January 12, 2017 by rm_

[s.lobanov]

ne-vlezay80

Это самые стрёмные десктопные карты, в провайдинге их никто не использует (если кто использует, значит это совсем зелёные админы пионернетов). Чинить это баг просто никому не интересно. Если дома нужен VLAN (зачем? ну ок, пусть нужен), то выше rm_ уже написал. Да и вообще, на всех картах, с которыми я работал (intel и broadcom куча разных) при установленном по дефолту L3MTU=1500 спокойно ходит трафик с VLAN (т.е. с L2MTU=1518).

[ne-vlezay80]

ne-vlezay80

Это самые стрёмные десктопные карты, в провайдинге их никто не использует (если кто использует, значит это совсем зелёные админы пионернетов). Чинить это баг просто никому не интересно. Если дома нужен VLAN (зачем? ну ок, пусть нужен), то выше rm_ уже написал. Да и вообще, на всех картах, с которыми я работал (intel и broadcom куча разных) при установленном по дефолту L3MTU=1500 спокойно ходит трафик с VLAN (т.е. с L2MTU=1518).

Зато этот realtek на всех материнских платах есть и во всех ноутбуках.

[s.lobanov]

ne-vlezay80

Ну и зачем на форум операторов приходить с этим десктопным вопросом? Будут вопросы по intel i350/x520/x710/подобному - велкам, а это реалтековское говно здесь никому не интересно

[andryas]

Да, упорству производителей нет предела. Такое впечатление, что этот чип уже в более чем 90% материнок, в некоторых даже по 2 шт сразу. И это ради совершенно копеечной экономии.

Но удивительно другое: несмотря на такую дикую популярность чипа, кривизна драйверов сего девайся удивительно слабо волнует разработчиков осей.

[s.lobanov]

andryas

Для десктопных задач он справляется и ладно.

[NiTr0]

Это самые стрёмные десктопные карты

не самые стремные. еще есть корявые атеросы, есть via (которая у меня вообще не запустилась у меня лет 5 назад), и есть куча гораздо менее известного шлачка (хотя по большей части pci и 100мбит, но все же) - настолько корявого, что оно даже под виндой с драйверами, идущими на диске с сетевкой, не работает :)

[tartila]

Да, упорству производителей нет предела. Такое впечатление, что этот чип уже в более чем 90% материнок, в некоторых даже по 2 шт сразу. И это ради совершенно копеечной экономии.

Но удивительно другое: несмотря на такую дикую популярность чипа, кривизна драйверов сего девайся удивительно слабо волнует разработчиков осей.

 

Да ладно вам, хороший десктоп адаптер то... Думаю (не проверял), что в провайдерстве его тоже можно применить на скоростях около 500-600 Mbit/s.

[andryas]

Думаю (не проверял), что в провайдерстве его тоже можно применить на скоростях около 500-600 Mbit/s.

 

В провайдерстве не столько скорости важны (хотя важны, конечно), сколько пакетная производительность, в рассматриваемом случае - загрузка процессора прерываниями адаптера. Другими словами, какая будет загрузка процесора сервера при 800 мегабит/с и 80 килопакетах/с? На Интелах - это от силы 10-20%. Какая загрузка будет при этом на рилтеке? По таймауту карточка отваливаться не будет? Панику дрова не вызовут?

 

Вот у меня на одном тазике (сервер) сейчас какой-то интел двухпортовый, скорость как раз около 700 мегабит; в одну сторону 185286 пакетов/с в другую 214013. Процессор занят на 8.84%. Не уверен, но, ИМХО, рилтеку там не место.

 

А на десктоп, может и хороший, не знаю. У меня на десктопах интеловские внешние, точно хорошие. Интегрированых даже не проверял.

[[anp/hsw]]

Сейчас карточки не так уж сильно по пакетной производительности отличаются. Во всяком случае в линуксе. Это раньше каждый драйвер писался отдельно совсем разными способами.

После введения механизма NAPI, уже достигнут кое-какой паритет. Конечно, у интелов есть куча очередей, offload'ов, которые несколько помогают, но если взять сферическое сравнение в вакууме типа "бюджетный intel e1000 с одним вектором прерываний" и "обычный Realtek 8169", то разницы в производительности там будет несколько процентов.

Что не отменяет того факта, что у новых реалтеков микрокод может тупо зависнуть, или еще какая хрень произойдет, которую на десктопах можно проигнорировать, а вот на серверах уже не выйдет.

[NiTr0]

' timestamp='1484983009' post=1364974]

но если взять сферическое сравнение в вакууме типа "бюджетный intel e1000 с одним вектором прерываний" и "обычный Realtek 8169", то разницы в производительности там будет несколько процентов.

таки нет. из личного опыта - замена forcedeth (пары) на i82576 2-портовую снизила нагрузку на 2-ядерный камень с 60-70% до 5-10%.

 

и да, NAPI реально работает только тогда когда камень в полке. до того - сетевка получила прерывание, приняла пакет, убедилась что в буфере пакетов больше нет (NAPI) и успокоилась, вернув управление юзерспейсу в ожидании очередного прерывания.

 

interrupt moderation + большие буфферы - то, что выгодно отличает любой интел.

[kayot]

замена forcedeth (пары) на i82576

Forcedeath нвидиевский это вообще не сетевка. Не нужно сравнивать ЭТО с православным реалтеком))

Оно и под виндой глючит, а уж под линуксом этот "драйвер" и плющит, и таращит, и не умеет он вообще ничего походу.

 

RTL бортовой у меня в одном из тазиков отпахал несколько лет, никаких нареканий. Замена на intel ET загрузку не изменила, +- те же 15-20%

Тазик роутил локалку+вебсервер/почта/сервисы, трафика с полгига.

[rm_]

После введения механизма NAPI, уже достигнут кое-какой паритет. Конечно, у интелов есть куча очередей, offload'ов, которые несколько помогают, но если взять сферическое сравнение в вакууме типа "бюджетный intel e1000 с одним вектором прерываний" и "обычный Realtek 8169", то разницы в производительности там будет несколько процентов.

Нифига подобного, проверяйте даже элементарный iperf полнодуплексный тест, даже речи не идёт про высокое PPS и т.д, на реалтеке 700+700 мбит, на e1000e/bnx2 900+900.

[andryas]

Под FreeBSD на некоторых задачах разница очень даже заметна. И, если на вебсервере, биллиге и т.д. рилтек как-то юзабелен в силу дефолтности, то на роутинге трафика большого числа юзеров получаем сразу 2 подарка: отжирание процессора прерываниями и периодические отвалы. По крайней мере на 8-ке проблемы возникали с заметной периодичностью. Решалось, кстати, отключением оффлоадов, а это ещё ухудшало производительность. Где-то год назад тестировал на 9-ке на 100 мегабитах (сугубо синтетика), где-то 50-60 килопакетов получил, сутки продержалось без отвалов. Но в рабочую машину (обновил веб-сервер) всё же поставил интел. Как-то надёжнее :)

[vlad11]

Но в рабочую машину (обновил веб-сервер) всё же поставил интел. Как-то надёжнее :)

 

Для веба реалтек - не критично. В вебе основная нагрузка на проц для Mysql и php.

 

P.S. Реалтек проверен на Фряхе и Дебиане.

[Ivan_83]

' timestamp='1484983009' post=1364974] Сейчас карточки не так уж сильно по пакетной производительности отличаются. Во всяком случае в линуксе. Это раньше каждый драйвер писался отдельно совсем разными способами. После введения механизма NAPI, уже достигнут кое-какой паритет.

Сколько ты сам лично дров сетевух под линух написал или хотя бы правил?

 

 

Под FreeBSD на некоторых задачах разница очень даже заметна. И, если на вебсервере, биллиге и т.д. рилтек как-то юзабелен в силу дефолтности, то на роутинге трафика большого числа юзеров получаем сразу 2 подарка: отжирание процессора прерываниями и периодические отвалы. По крайней мере на 8-ке проблемы возникали с заметной периодичностью.

Восьмёрка была сильно давно.

 

 

Для веба реалтек - не критично. В вебе основная нагрузка на проц для Mysql и php.

Веб разный бывает, в том числе и отдача статических файлов. Вот на статике хорошо видно что оффлоадингов рылотеку не хватает, но видно это хорошо только на слабых процах.

[NiTr0]

Forcedeath нвидиевский это вообще не сетевка. Не нужно сравнивать ЭТО с православным реалтеком))

ну почему же, вполне себе годная сетевка, не хуже рылтеков...

 

Оно и под виндой глючит, а уж под линуксом этот "драйвер" и плющит, и таращит, и не умеет он вообще ничего походу.

ни разу не плющило драйвер, просто нагрузка на проц была большая. оно-то и понятно - никакого interrupt moderation нет и в помине, неоткуда ему там взяться при микроскопических буферах пакетов (у рылтека буфера к примеру на целых 16 килобайт на rx и целых 8 кб на tx...

 

Нифига подобного, проверяйте даже элементарный iperf полнодуплексный тест, даже речи не идёт про высокое PPS и т.д, на реалтеке 700+700 мбит, на e1000e/bnx2 900+900.

хз, на больших фрагментах я на forcedeth прекрасно гигабит вытягивал (wget - 100МБ/с) на стенде. iperf не гонял как-то, могу попробовать...

 

Вот на статике хорошо видно что оффлоадингов рылотеку не хватает

каких оффлоадингов ему не хватает-то? КС оффлоадит на ура. а фрагментация - на роутерах оффлоадинги отключаются вообще; тем не менее интел и реалтек сильно отличаются по нагрузке на проц...