Jump to content
Калькуляторы

Новые дрова от Яндеха Под Фрю 7/8

FreeBSD 7.4-STABLE теперь не могу собрать ни em-6.9.6-RELENG7-yandex-1.36.2.17.tar.gz ни e1000-7.0.5-RELENG7-yandex-1.36.2.18.tar.gz

Может кто подскажет где копать?

Share this post


Link to post
Share on other sites
А теперь попробуйте насоздавать, скажем на igb3 скриптом кучку vlan-ов и посмотрите, на какой штуке нарветесь на "could not setup received structures" или что-то подобное, при

 

loader.conf

--------------------

hw.igb.rxd=4096

hw.igb.txd=4096

hw.igb.num_queues=0

hw.igb.lro=0

hw.igb.enable_msix=1

--------------------

 

 

 

Причем если поиграть с hw.igb.num_queues, то можно подобрать такое количество очередей, при котором на ошибки наступать перестаем, но и тогда под нагрузкой ловятся косяки.

Например у меня перестает показывать глюки при инициализации с hw.igb.num_queues=7, но более-менее стабильно работает только при hw.igb.num_queues=6 (по умолчанию, без настройки параметраhw.igb.num_queues, на моей конфигурации создается по 11 очередей)

Если поднимать lagg на igb, то и вовсе hw.igb.num_queues=3 - предел, но ловим глюки в работа практически сразу. Параметров крутили много.

И это при 2xXeon X5650 (всего 24 потока). Так что пока все печально.

 

PT с дровами yandex на той же конфигурации пока недостижим.

С hw.igb.rxd=4096 и hw.igb.txd=4096 сообщение "could not setup received structures" вылетало на старте системы (2 valn-a), но убрав их, неделю живет - полет номальный (700/500 Мбит/с отдачи/входа )

 

На предидущей версии дров igb (из FreeBSD 8.0) в моем случае нет практически никакой разницы в производительности с родными em, в одинаковых тазиках жуют одинаково трафика 800/400 вход/выход NAT, Netflow, Шейпинг

 

Доброй ночи!

 

Кто-нибудь может посоветовать, что сделать с сетевухами igb, чтобы они не глючили с lagg и vlan?

Встроенные bge давали дропы уже на 300 мбит, поэтому купил igb за несколько сотен баксов, а с ними тоже фигня :(

 

Раз в сутки падает!

LAGG не разваливается, но перестает принимать пакеты. Причем видно, что со свитча они уходят. На сетевухах на входе не видно, и прерывания они не генерируют (может иногда одно -другое, но не соотв. поступлению пакетов).

 

Сейчас обновляют с FreeBSD 8.1 STABLE до 8.2 RELEASE. Надеюсь что поможет, но по опыту - вряд ли.

Edited by xOr

Share this post


Link to post
Share on other sites
А теперь попробуйте насоздавать, скажем на igb3 скриптом кучку vlan-ов и посмотрите, на какой штуке нарветесь на "could not setup received structures" или что-то подобное, при

 

loader.conf

--------------------

hw.igb.rxd=4096

hw.igb.txd=4096

hw.igb.num_queues=0

hw.igb.lro=0

hw.igb.enable_msix=1

--------------------

 

 

 

Причем если поиграть с hw.igb.num_queues, то можно подобрать такое количество очередей, при котором на ошибки наступать перестаем, но и тогда под нагрузкой ловятся косяки.

Например у меня перестает показывать глюки при инициализации с hw.igb.num_queues=7, но более-менее стабильно работает только при hw.igb.num_queues=6 (по умолчанию, без настройки параметраhw.igb.num_queues, на моей конфигурации создается по 11 очередей)

Если поднимать lagg на igb, то и вовсе hw.igb.num_queues=3 - предел, но ловим глюки в работа практически сразу. Параметров крутили много.

И это при 2xXeon X5650 (всего 24 потока). Так что пока все печально.

 

PT с дровами yandex на той же конфигурации пока недостижим.

С hw.igb.rxd=4096 и hw.igb.txd=4096 сообщение "could not setup received structures" вылетало на старте системы (2 valn-a), но убрав их, неделю живет - полет номальный (700/500 Мбит/с отдачи/входа )

 

На предидущей версии дров igb (из FreeBSD 8.0) в моем случае нет практически никакой разницы в производительности с родными em, в одинаковых тазиках жуют одинаково трафика 800/400 вход/выход NAT, Netflow, Шейпинг

 

Доброй ночи!

 

Кто-нибудь может посоветовать, что сделать с сетевухами igb, чтобы они не глючили с lagg и vlan?

Встроенные bge давали дропы уже на 300 мбит, поэтому купил igb за несколько сотен баксов, а с ними тоже фигня :(

 

Раз в сутки падает!

LAGG не разваливается, но перестает принимать пакеты. Причем видно, что со свитча они уходят. На сетевухах на входе не видно, и прерывания они не генерируют (может иногда одно -другое, но не соотв. поступлению пакетов).

 

Сейчас обновляют с FreeBSD 8.1 STABLE до 8.2 RELEASE. Надеюсь что поможет, но по опыту - вряд ли.

Я так мучался год назад с 8.0. Карточки на борту интел em. поставил семёрку (на тот момент 7.2) и забыл проблему. только вот сейчас обновился до 7.4, а драйвера от яндекса не собираются, пока на родных bsd работаю, проблем вроде как не возникает.

Share this post


Link to post
Share on other sites
http://people.yandex-team.ru/~wawa/em-7.1.....17.2.25.tar.gz

эти не пробовали на 8.2 еще?

В 8 есть netisr - 10 строчек в ether_(input|demux) раскладывают обработку пакетов по нужному количеству netisr-очередей независимо от карточки и драйвера. Зачем колбаситься с фаерволом, натом и шейпером в контексте прерывания, когда нужно быстренько принять пачку пакетов, положить их в соответствующую очередь и освободить обработчик?

   10 root       171 ki31     0K    64K RUN     1 1369.1 99.56% {idle: cpu1}
   10 root       171 ki31     0K    64K RUN     0 1301.5 97.75% {idle: cpu0}
   10 root       171 ki31     0K    64K RUN     3 1318.7 95.65% {idle: cpu3}
   10 root       171 ki31     0K    64K CPU2    2 1401.5 91.89% {idle: cpu2}
   11 root       -44    -     0K   400K WAIT    2 197.5H  6.01% {swi1: netisr 2}
   11 root       -44    -     0K   400K CPU0    0 192.8H  4.74% {swi1: netisr 0}
   11 root       -44    -     0K   400K WAIT    3 192.8H  4.74% {swi1: netisr 3}
   11 root       -44    -     0K   400K WAIT    1 192.0H  4.54% {swi1: netisr 1}
   11 root       -68    -     0K   400K CPU3    3 101.0H  3.47% {irq259: em1:rx 0}
51800 root        45    0   118M 57808K select  0  67.0H  3.22% {mpd5}
   11 root       -68    -     0K   400K WAIT    1  42.4H  1.03% {irq256: em0:rx 0}
   11 root       -68    -     0K   400K WAIT    0  19.6H  0.73% {irq257: em0:tx 0}
   11 root       -68    -     0K   400K WAIT    0  25.2H  0.63% {irq260: em1:tx 0}
    0 root       -68    0     0K   160K -       0  59.3H  0.00% {dummynet}

Share this post


Link to post
Share on other sites

ну у кого под 8.2 нормально заработало?

с последними драйверами от февраля 2011

Share this post


Link to post
Share on other sites

Интерестно когда igb будут рабочими :)

Share this post


Link to post
Share on other sites

FreeBSD 7.3-RELEASE-p4, дрова e1000-7.0.5-RELENG7-yandex-1.36.2.18, сетевуха em0 Intel 82566DM. При создании/удалении вланов (порядка 200, меньше не проверял) перестает работать TCP; ARP, UDP, ICMP работают нормально. Помогает ifconfig em0 -rxcsum. Также странно, что если вланы создаются при загрузке системы rc-скриптом, все работает нормально до первого создания/удаления влана ручками.

Share this post


Link to post
Share on other sites
Интерестно когда igb будут рабочими :)
За 11 дней аптайма полет нормальный.

Средняя нагрузка порядка 22 кппс за эти 11 дней. В пики доходит до 55кппс. Пока моим кастомерам больше не надо. :)

# uname -rs
FreeBSD 8.2-RELEASE
# netstat -id|grep ^igb
igb0   1500 <Link#1>      00:1b:21:4a:4e:1c 18891344798     0     0 17396457783     0     0    0
igb1   1500 <Link#2>      00:1b:21:4a:4e:1d 17980987850     0     0 18371618493     0     0    0
igb1   1500 192.168.0.0/1 192.168.0.1       37315897     -     - 28535342     -     -    -
# uptime
12:41  up 11 days,  5:41, 5 users, load averages: 0,03 0,09 0,08
# sysctl dev.igb|grep desc:
dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.7
dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.7
#

Share this post


Link to post
Share on other sites
FreeBSD 7.3-RELEASE-p4, дрова e1000-7.0.5-RELENG7-yandex-1.36.2.18, сетевуха em0 Intel 82566DM. При создании/удалении вланов (порядка 200, меньше не проверял) перестает работать TCP; ARP, UDP, ICMP работают нормально. Помогает ifconfig em0 -rxcsum. Также странно, что если вланы создаются при загрузке системы rc-скриптом, все работает нормально до первого создания/удаления влана ручками.
Попробуйте свежие e1000 драйвера из FreeBSD-CURRENT. 3-4 дня назад их внес Jack и скоро уже будет MFC.

Вроде он внедрил массу доработок.

 

з.ы. опсь, а для этой темы это оффтопик.. ;)

Edited by Laa

Share this post


Link to post
Share on other sites
С hw.igb.rxd=4096 и hw.igb.txd=4096 сообщение "could not setup received structures" вылетало на старте системы (2 valn-a), но убрав их, неделю живет - полет номальный (700/500 Мбит/с отдачи/входа )

Это как бы не выход =)

у меня на двухядерном ксеоне
CPU: Intel(R) Xeon(R) CPU           E5503  @ 2.00GHz (2002.51-MHz K8-class CPU)

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

hw.igb.num_queues=2

Share this post


Link to post
Share on other sites

а что в 8.2 следует использовать для успокоения dummynet? Поставил на тестирование 8.2 релиз, трафика мегабит 20-30 всего, dummynet периодически съедает до 100% одного ядра без всяких видимых причин (каких-то увеличений pps и mbps в эти моменты нет) . Рядом в таком-же тазу стоит 7.х с яндекс-драйверами + сpuset и такого не наблюдается на трафе в десятки раз большем. А тут что?

Edited by umike

Share this post


Link to post
Share on other sites

а что в 8.2 следует использовать для успокоения dummynet? Поставил на тестирование 8.2 релиз, трафика мегабит 20-30 всего, dummynet периодически съедает до 100% одного ядра без всяких видимых причин (каких-то увеличений pps и mbps в эти моменты нет) . Рядом в таком-же тазу стоит 7.х с яндекс-драйверами + сpuset и такого не наблюдается на трафе в десятки раз большем. А тут что?

Из личных наблюдений - даминет должен жить на одном ядре с прерываниями от таймера, как правило это ядро 0, по возможности на этом ядре не должно жить больше ничего. Прибивание даминета на другие ядра вызывало крепкие скачки нагрузки независимо от трафика, сам трафик вроде как ни на что и не влияет. Это 8-stable еще со времен 8.1, на неделе какраз собирался затягивать свежий stable для экспериментов.

Share this post


Link to post
Share on other sites

# netstat -id|grep ^igb

igb0 1500 <Link#1> 00:1b:21:4a:4e:1c 18891344798 0 0 17396457783 0 0 0

igb1 1500 <Link#2> 00:1b:21:4a:4e:1d 17980987850 0 0 18371618493 0 0 0

igb1 1500 192.168.0.0/1 192.168.0.1 37315897 - - 28535342 - - -

 

Вот это лишнее, ИМХО, интерфейсов м.б. тысячи, лучше так:

 

netstat -id -I igb0 && netstat -id -I igb1

Edited by Deac

Share this post


Link to post
Share on other sites

Из личных наблюдений - даминет должен жить на одном ядре с прерываниями от таймера, как правило это ядро 0, по возможности на этом ядре не должно жить больше ничего. Прибивание даминета на другие ядра вызывало крепкие скачки нагрузки независимо от трафика, сам трафик вроде как ни на что и не влияет. Это 8-stable еще со времен 8.1, на неделе какраз собирался затягивать свежий stable для экспериментов.

 

Тоже из наблюдений,

cpuset -l 0 -t $(procstat -t 0 | awk '/dummynet/ {print $2}')

приносит облегчение.

Share this post


Link to post
Share on other sites
  10 root   	171 ki31 	0K    64K RUN 	1 1369.1 99.56% {idle: cpu1}
  10 root   	171 ki31 	0K    64K RUN 	0 1301.5 97.75% {idle: cpu0}
  10 root   	171 ki31 	0K    64K RUN 	3 1318.7 95.65% {idle: cpu3}
  10 root   	171 ki31 	0K    64K CPU2    2 1401.5 91.89% {idle: cpu2}
  11 root   	-44    - 	0K   400K WAIT    2 197.5H  6.01% {swi1: netisr 2}
  11 root   	-44    - 	0K   400K CPU0    0 192.8H  4.74% {swi1: netisr 0}
  11 root   	-44    - 	0K   400K WAIT    3 192.8H  4.74% {swi1: netisr 3}
  11 root   	-44    - 	0K   400K WAIT    1 192.0H  4.54% {swi1: netisr 1}
  11 root   	-68    - 	0K   400K CPU3    3 101.0H  3.47% {irq259: em1:rx 0}
51800 root        45    0   118M 57808K select  0  67.0H  3.22% {mpd5}
  11 root   	-68    - 	0K   400K WAIT    1  42.4H  1.03% {irq256: em0:rx 0}
  11 root   	-68    - 	0K   400K WAIT    0  19.6H  0.73% {irq257: em0:tx 0}
  11 root   	-68    - 	0K   400K WAIT    0  25.2H  0.63% {irq260: em1:tx 0}
   0 root   	-68    0 	0K   160K -   	0  59.3H  0.00% {dummynet}

 

это какая версия? Настройками не поделитесь? У меня если взять дефолтные дрова на 8.2 картина выглядит как-то вовсе безрадостно

net.isr.numthreads: 4

net.isr.bindthreads: 0

net.isr.maxthreads: 4

net.isr.direct: 0

net.isr.direct_force: 0

 

 

   11 root 	171 ki31 	0K	32K CPU3	3  39.2H 100.00% {idle: cpu3}
  11 root 	171 ki31 	0K	32K RUN 	1  38.6H 100.00% {idle: cpu1}
  11 root 	171 ki31 	0K	32K CPU0	0  38.3H 100.00% {idle: cpu0}
  11 root 	171 ki31 	0K	32K CPU2	2  37.6H 91.26% {idle: cpu2}
  12 root 	-44	- 	0K   192K WAIT	2 178:44 15.28% {swi1: netisr 3}
  12 root 	-44	- 	0K   192K WAIT	3  86:39  1.37% {swi1: netisr 0}
0 root 	-68	0 	0K	96K -   	0 108:37  0.00% {dummynet}
0 root 	-68	0 	0K	96K -   	0  22:00  0.00% {em1 taskq}
0 root 	-68	0 	0K	96K -   	3  15:50  0.00% {em0 taskq}
  12 root 	-32	- 	0K   192K WAIT	1   6:51  0.00% {swi4: clock}

Share this post


Link to post
Share on other sites

это какая версия? Настройками не поделитесь? У меня если взять дефолтные дрова на 8.2 картина выглядит как-то вовсе безрадостно

net.isr.numthreads: 4

net.isr.bindthreads: 0

net.isr.maxthreads: 4

net.isr.direct: 0

net.isr.direct_force: 0

Настройками не поделюсь, не рулится оно простыми sysctl. Для нормального распаралеливания нужен нормальный flowid, я его рассчитал примерно вот так:

diff -Nur /usr/src/sys/net/if_ethersubr.c /root/src/sys/net/if_ethersubr.c
--- /usr/src/sys/net/if_ethersubr.c	2010-09-12 01:02:36.000000000 +0300
+++ /root/src/sys/net/if_ethersubr.c	2010-11-11 22:57:29.000000000 +0200
@@ -621,6 +622,11 @@
		ifp->if_imcasts++;
	}

+	m->m_flags |= M_FLOWID;
+	m->m_pkthdr.flowid =  eh->ether_dhost[0] + eh->ether_dhost[1] + eh->ether_dhost[2] + eh->ether_dhost[3] + eh->ether_dhost[4] + eh->ether_dhost[5];
+	m->m_pkthdr.flowid += eh->ether_shost[0] + eh->ether_shost[1] + eh->ether_shost[2] + eh->ether_shost[3] + eh->ether_shost[4] + eh->ether_shost[5];
+
+
#ifdef MAC
	/*
	 * Tag the mbuf with an appropriate MAC label before any other
@@ -830,6 +836,29 @@
		if ((m = ip_fastforward(m)) == NULL)
			return;
		isr = NETISR_IP;
+
+		struct ipheader {
+		    u_char offset [12]; //ip header fields not actually needed here
+		    u_char src [4]; //ip src
+		    u_char dst [4]; //ip dst
+		} __packed __aligned(4);
+
+		if (m->m_pkthdr.len < sizeof(struct ipheader)) { 		//from ip_fastforward
+		    if_printf(ifp, "flowid math: discard frame with too small header\n");
+		    goto discard;
+		}
+		if (m->m_len < sizeof (struct ipheader) &&
+		    (m = m_pullup(m, sizeof (struct ipheader))) == NULL) {      //ip_fastforward
+		    if_printf(ifp, "flowid math: discard frame at pullup\n");
+			return;		/* mbuf already free'd */
+		}
+		struct ipheader *ip;
+		ip = mtod(m, struct ipheader *);
+		m->m_pkthdr.flowid += ip->src[0] + ip->src[1] + ip->src[2] + ip->src[3];
+		m->m_pkthdr.flowid += ip->dst[0] + ip->dst[1] + ip->dst[2] + ip->dst[3];
+
+//		if_printf(ifp, "Calculated flow id %d\n", m->m_pkthdr.flowid);
+
		break;

	case ETHERTYPE_ARP:

Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то.

Edited by make.kernel

Share this post


Link to post
Share on other sites

насколько я понял активно используется flowtable. И не впадает в ступор?

Share this post


Link to post
Share on other sites

Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то.

А пробовали добавить аналогичный код для Ethernet фреймов (PPPoE)? судя по netisr.h можно и ethernet фреймы так обработать. И можно еще подумать над hash функцией от исходных данных.

Edited by adeep

Share this post


Link to post
Share on other sites

насколько я понял активно используется flowtable. И не впадает в ступор?

flowtable тут не причем.

Share this post


Link to post
Share on other sites

Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то.

А пробовали добавить аналогичный код для Ethernet фреймов (PPPoE)? судя по netisr.h можно и ethernet фреймы так обработать. И можно еще подумать над hash функцией от исходных данных.

Не пробовал, просто и так трафик размазался достаточно хорошо.

Share this post


Link to post
Share on other sites

Поставил дрова от яндекса, по умолчанию каждая сетевая паралелится на 2 ядра

0 root 70 0 0K 240K CPU4 4 74:16 38.13% {em1_rx0_0}

0 root 66 0 0K 240K PKWAIT 5 66:16 36.18% {em0_rx0_0}

0 root 67 0 0K 240K PKWAIT 1 66:21 35.64% {em0_rx0_1}

0 root 65 0 0K 240K CPU6 6 74:09 34.67% {em1_rx0_1}

можно ли как-то заставить каждую сетевую паралелится на 4 ядра например?

Share this post


Link to post
Share on other sites

Какие дрова сейчас ставить лучше для карточек igb (82576), родные последние с сайта Intel или дрова от wawa? FreeBSD 7.4-STABLE, машина в роли роутера.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this