Перейти к содержимому
Калькуляторы

Новые дрова от Яндеха Под Фрю 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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А теперь попробуйте насоздавать, скажем на 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. Надеюсь что поможет, но по опыту - вряд ли.

Изменено пользователем xOr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А теперь попробуйте насоздавать, скажем на 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 работаю, проблем вроде как не возникает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

http://people.yandex-team.ru/~wawa/em-7.1.....17.2.25.tar.gz

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

Изменено пользователем fenix-vt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хм, а как насчет 7.4?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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}

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как насчет pf, например?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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-скриптом, все работает нормально до первого создания/удаления влана ручками.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Интерестно когда 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
#

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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.

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

 

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

Изменено пользователем Laa

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем umike

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

# 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

Изменено пользователем Deac

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

  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}

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

это какая версия? Настройками не поделитесь? У меня если взять дефолтные дрова на 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 какой-то.

Изменено пользователем make.kernel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем adeep

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поставил дрова от яндекса, по умолчанию каждая сетевая паралелится на 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 ядра например?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.