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

Тюнинг ixgbe (ix) под freebsd 8.2 Зашкаливает нагрузка по прерываниям

У кого есть опыт тюнинга двухголовых 10Г карточек (520-SR2) под фрю 8.2 ?

Столкнулся с тем, что при относительно небольшом трафике зашкаливают прерывания.

На машинке ipfw nat + dummynet.

Трафика пока залил в нее в пиках по 800Mbps IN и OUT, получил 60-70% interrupts на каждое ядро.

Дрова сетевухи 2.4.4

Фря amd64.

 

Кручение hw.ixgbe.rxd, dev.ix.0.rx_processing_limit и т.п вообще не дает никаких отличий.

Запустить polling банально не удалось - есть подозрение, что он тупо не поддерживается на 10Г карточках.

Share this post


Link to post
Share on other sites

sysctl бы показать. loader.conf, ядро дефолт?

Share this post


Link to post
Share on other sites

для начала убрать все упоминания о поллинге из ядра

Share this post


Link to post
Share on other sites

loader.conf

vm.kmem_size=1G
net.inet.tcp.syncache.hashsize=1024
net.inet.tcp.syncache.bucketlimit=100
net.inet.tcp.tcbhashsize=4096


kern.ipc.maxsockbuf=16777216      # kernel socket buffer space
kern.ipc.nmbclusters=262144       # kernel mbuf space raised 275MB of kernel dedicated ram
kern.ipc.somaxconn=32768          # size of the listen queue for accepting new TCP connections
kern.ipc.maxsockets=204800        # increase the limit of the open sockets
kern.randompid=348                # randomized processes id's
net.inet.icmp.icmplim=50          # reply to no more than 50 ICMP packets per sec
net.inet.ip.process_options=0     # do not processes any TCP options in the TCP headers
net.inet.ip.redirect=0            # do not allow ip header redirects
net.inet.ip.rtexpire=2            # route cache expire in two seconds
net.inet.ip.rtminexpire=2         # "
net.inet.ip.rtmaxcache=256        # route cache entries increased
net.inet.icmp.drop_redirect=1     # drop icmp redirects
net.inet.tcp.blackhole=2          # drop any TCP packets to closed ports
net.inet.tcp.delayed_ack=0        # no need to delay ACK's
net.inet.tcp.drop_synfin=1        # drop TCP packets which have SYN and FIN set
net.inet.tcp.msl=7500             # close lost tcp connections in 7.5 seconds (default 30)
net.inet.tcp.nolocaltimewait=1    # do not create TIME_WAIT state for localhost
net.inet.tcp.path_mtu_discovery=0 # disable MTU path discovery
net.inet.tcp.recvbuf_max=16777216 # TCP receive buffer space
net.inet.tcp.recvspace=8192       # decrease buffers for incoming data
net.inet.tcp.sendbuf_max=16777216 # TCP send buffer space
net.inet.tcp.sendspace=16384      # decrease buffers for outgoing data
net.inet.udp.blackhole=1          # drop any UDP packets to closed ports

hw.ixgbe.rxd=4096
hw.ixgbe.txd=4096
hw.ixgbe.rx_process_limit=4096
hw.ixgbe.max_interrupt_rate=10240

 

sysctl.conf

net.inet.ip.fw.one_pass=0
net.inet.ip.dummynet.io_fast=1
net.inet.ip.dummynet.hash_size=32768
net.inet.ip.dummynet.pipe_slot_limit=2048
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
kern.ipc.maxsockbuf=2097152
net.inet.ip.dummynet.io_fast=1
net.inet.ip.dummynet.hash_size=16384
net.inet.ip.dummynet.pipe_slot_limit=2048
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
net.inet.udp.maxdgram=57344
net.inet.tcp.sendspace=65535
net.inet.udp.recvspace=65535
net.inet.ip.intr_queue_maxlen=5000
kern.ipc.shmmax=67108864
kern.ipc.maxsockbuf=83886080
net.route.netisr_maxqlen=4096

 

Ядро перекомпилено с добавлением следующих опций:

 

options         IPFIREWALL
options         IPFIREWALL_FORWARD
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         IPFIREWALL_NAT
options         LIBALIAS
options         DUMMYNET
options         DEVICE_POLLING
options         PANIC_REBOOT_WAIT_TIME=1
options         HZ="1000"

Share this post


Link to post
Share on other sites

для начала убрать все упоминания о поллинге из ядра

 

Без polling'а как раз и начинал.

После уже от безысходности перекомпилил ядро с поллингом, однако включить поллинг не удалось (ifconfig ix0 polling) не дает никакого эффекта, по ifconfig среди опций POLLING не появляется.

 

В догонку при старте системы выполняю еще вот что:

 

ifconfig ix0 -rxcsum -tso -txcsum lro
ifconfig ix1 -rxcsum -tso -txcsum lro

Share this post


Link to post
Share on other sites

для начала убрать все упоминания о поллинге из ядра

 

Без polling'а как раз и начинал.

После уже от безысходности перекомпилил ядро с поллингом, однако включить поллинг не удалось (ifconfig ix0 polling) не дает никакого эффекта, по ifconfig среди опций POLLING не появляется.

 

В догонку при старте системы выполняю еще вот что:

 

ifconfig ix0 -rxcsum -tso -txcsum lro
ifconfig ix1 -rxcsum -tso -txcsum lro

В линуксовой версии по поводу LRO написано следуюеще:

 

IMPORTANT NOTE

==============

 

WARNING: The ixgbe driver compiles by default with the LRO (Large Receive

Offload) feature enabled. This option offers the lowest CPU utilization for

receives, but is completely incompatible with *routing/ip forwarding* and

*bridging*. If enabling ip forwarding or bridging is a requirement, it is

necessary to disable LRO using compile time options as noted in the LRO

section later in this document. The result of not disabling LRO when combined

with ip forwarding or bridging can be low throughput or even a kernel panic.

Share this post


Link to post
Share on other sites

net.inet.tcp.*

 

net.inet.udp.*

 

Вообще к роутингу отношения не имеют, и полностью тюнятся из сисцтл, в лоадере тюнится только то, что не тюнится из сисцтл.

 

kern.ipc.* вроде только из лоадера, и то возможно не всё.

 

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

 

Ещё, проверьте, всё что вы в лоадере прописали на самом деле применилось или вам только кажется.

 

Насчёт поллинга - не факт что его из драйверов не выкинули как депрекейтед.

 

 

Share this post


Link to post
Share on other sites

В любом случае, нагрузку дают не сами аппаратные прерывания, а обработка пакетов фаерволом/шейпером и NAT. Я бы вместо бесполезного тюнинга сетевого стека тюнинговал как раз 'ipfw nat + dummynet'.

Share this post


Link to post
Share on other sites

Перекомпилил ядро без POLLING, проверил что по факту тюнится и не тюнится указанное в loader.conf и sysctl.conf - все нормально.

Без вкомпиленного polling ситуация не изменилась, вот что имеем:

 

10gx2# netstat -I ix0 1
           input          (ix0)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
    39161     0     0   34748048      31454     0   24910825     0
    38159     0     0   31683360      33062     0   27845440     0

 

last pid: 21019;  load averages:  0.00,  0.04,  0.06                                                                                                                         up 0+00:14:55  14:01:07
104 processes: 5 running, 68 sleeping, 31 waiting
CPU 0:  0.0% user,  0.0% nice,  1.1% system, 23.3% interrupt, 75.6% idle
CPU 1:  0.0% user,  0.0% nice,  0.4% system, 27.8% interrupt, 71.8% idle
CPU 2:  0.0% user,  0.0% nice,  0.4% system, 26.3% interrupt, 73.3% idle
CPU 3:  0.0% user,  0.0% nice,  0.8% system, 25.9% interrupt, 73.3% idle
Mem: 16M Active, 12M Inact, 234M Wired, 292K Cache, 11M Buf, 3552M Free
Swap: 10G Total, 10G Free

 PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
  11 root     171 ki31     0K    64K RUN     0  11:20 79.79% {idle: cpu0}
  11 root     171 ki31     0K    64K CPU1    1  12:18 78.47% {idle: cpu1}
  11 root     171 ki31     0K    64K RUN     2  12:18 77.98% {idle: cpu2}
  11 root     171 ki31     0K    64K CPU3    3  12:27 73.78% {idle: cpu3}
  12 root     -68    -     0K   496K WAIT    1   1:22 15.77% {irq262: ix1:que }
  12 root     -68    -     0K   496K WAIT    3   1:17 15.19% {irq264: ix1:que }
  12 root     -68    -     0K   496K WAIT    2   1:16 15.09% {irq263: ix1:que }
  12 root     -68    -     0K   496K WAIT    0   1:15 12.89% {irq261: ix1:que }
  12 root     -68    -     0K   496K WAIT    1   1:07 12.35% {irq257: ix0:que }
  12 root     -68    -     0K   496K WAIT    0   1:04 11.18% {irq256: ix0:que }
  12 root     -68    -     0K   496K WAIT    2   1:02 10.35% {irq258: ix0:que }
  12 root     -68    -     0K   496K WAIT    3   1:03  9.47% {irq259: ix0:que }

 

10gx2# ipfw show
00005      804       60731 allow ip from any to me
00005     1212      256223 allow ip from me to any
00010      225       15474 deny ip from any to any dst-port 135,137,139,445 in recv ix0
00015        0           0 skipto 20 ip from table(4) to any dst-port 25 out xmit ix1
00016      268       15776 deny ip from any to any dst-port 25 out xmit ix1
00050   103722    23160900 skipto 150 ip from table(1) to table(3) in recv ix0
00100 22127152 16616245814 pipe tablearg ip from table(1) to any in recv ix0
00120       30        1200 skipto 150 ip from any to table(5) in recv ix0
00130     1336       86530 fwd 127.0.0.1,49850 ip from not table(1) to any dst-port 80 in recv ix0
00140     3609      236281 deny ip from not table(1) to any in recv ix0
00200 22225977 16632525619 nat tablearg ip from table(20) to any out xmit ix1
00201 22228364 16633902478 allow ip from any to any out xmit ix1
00300 19723527 15485774039 nat tablearg ip from any to table(21) in recv ix1
00350   110672    84866702 skipto 1000 ip from table(3) to table(1) out xmit ix0
00401 19150332 15367589943 pipe tablearg ip from any to table(2) out xmit ix0
65535 60720126 47454877202 allow ip from any to any

 

Подправлены исходники, чтобы можно было сделать более 16 instances ната (сейчас их сделано 255), реально правда используется около 50.

Натится путем нарезки /15 серых IP кусками по /26 и назначением по /26 на отдельный IP из пула НАТа (пул ната /24).

Собственно сделано по кругу (т.е. a.b.c.0/26 -> .1, a.b.c.64/26 -> .2 после дохода до .255 опять переходим к .1) сделано было с той целью чтобы максимально равномерно распределить серые ипы по пабликам.

 

Какие есть мысли - что тут можно потюнить чтобы не получать по 25% прерываний при трафике в 20-25Мбайт/с ?

Share this post


Link to post
Share on other sites

Я не уверен в необходимости выставления hw.ixgbe.max_interrupt_rate=10240. Чем не понравился дефолтный Dynamic?

Share this post


Link to post
Share on other sites

Я не уверен в необходимости выставления hw.ixgbe.max_interrupt_rate=10240. Чем не понравился дефолтный Dynamic?

 

Это один из экспериментов - изменение этого параметра опять же не дает никакого эффекта.

Share this post


Link to post
Share on other sites

Я не уверен в необходимости выставления hw.ixgbe.max_interrupt_rate=10240. Чем не понравился дефолтный Dynamic?

нет смысла. стардартные параметры от яндекса великолепно лопатят до 920 мегабит.

http://forum.nag.ru/forum/index.php?showtopic=71822&view=findpost&p=666608

Edited by t00r

Share this post


Link to post
Share on other sites

Я не уверен в необходимости выставления hw.ixgbe.max_interrupt_rate=10240. Чем не понравился дефолтный Dynamic?

нет смысла. стардартные параметры от яндекса великолепно лопатят до 920 мегабит.

http://forum.nag.ru/forum/index.php?showtopic=71822&view=findpost&p=666608

 

Отличие вашей истории от моей в том, что у вас гигабитные сетевухи, а у меня 10Г. На гигабитных я отлично в полку прогружаю натом с шейпингом гиг, а вот с этими карточками сплошная беда.

Share this post


Link to post
Share on other sites

Покажите sysctl dev.ixgbe.0 | grep -v ": 0"

Share this post


Link to post
Share on other sites

Покажите sysctl dev.ixgbe.0 | grep -v ": 0"

 

Оно не ixgbe, а просто ix значится в dev.

Сейчас откатился на 2.3.8 - ничего опять же не изменилось, что 2.4.4 что эти - результат идентичный - прерывания зашкаливают.

Сейчас даже отказался от ipfw nat в пользу PFNAT, результат опять же такой же. При трафике в 40Мбайт/с в каждую сторону я имею по 33-35% загрузку прерываниями каждого из ядер.

 

===

10gx2# sysctl dev.ix.0 | grep -v ": 0"
dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.3.8
dev.ix.0.%driver: ix
dev.ix.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PEG1.S6F0
dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0003 class=0x020000
dev.ix.0.%parent: pci2
dev.ix.0.flow_control: 0
dev.ix.0.enable_aim: 1
dev.ix.0.rx_processing_limit: 4096
dev.ix.0.link_irq: 2
dev.ix.0.queue0.interrupt_rate: 1000000
dev.ix.0.queue0.txd_head: 854
dev.ix.0.queue0.txd_tail: 856
dev.ix.0.queue0.tx_packets: 6660945
dev.ix.0.queue0.rxd_head: 3754
dev.ix.0.queue0.rxd_tail: 3753
dev.ix.0.queue0.rx_packets: 6471341
dev.ix.0.queue0.rx_bytes: 3128748031
dev.ix.0.queue1.interrupt_rate: 10638
dev.ix.0.queue1.txd_head: 1736
dev.ix.0.queue1.txd_tail: 1736
dev.ix.0.queue1.tx_packets: 6995827
dev.ix.0.queue1.rxd_head: 1119
dev.ix.0.queue1.rxd_tail: 1118
dev.ix.0.queue1.rx_packets: 6718559
dev.ix.0.queue1.rx_bytes: 3938881610
dev.ix.0.queue2.interrupt_rate: 10638
dev.ix.0.queue2.txd_head: 2871
dev.ix.0.queue2.txd_tail: 2871
dev.ix.0.queue2.tx_packets: 6775157
dev.ix.0.queue2.rxd_head: 275
dev.ix.0.queue2.rxd_tail: 272
dev.ix.0.queue2.rx_packets: 6119703
dev.ix.0.queue2.rx_bytes: 3500565337
dev.ix.0.queue3.interrupt_rate: 1000000
dev.ix.0.queue3.txd_head: 1501
dev.ix.0.queue3.txd_tail: 1501
dev.ix.0.queue3.tx_packets: 6362589
dev.ix.0.queue3.rxd_head: 3893
dev.ix.0.queue3.rxd_tail: 3891
dev.ix.0.queue3.rx_packets: 6844212
dev.ix.0.queue3.rx_bytes: 4386162945
dev.ix.0.mac_stats.local_faults: 6
dev.ix.0.mac_stats.remote_faults: 1
dev.ix.0.mac_stats.total_octets_rcvd: 15057984332
dev.ix.0.mac_stats.good_octets_rcvd: 15057984332
dev.ix.0.mac_stats.total_pkts_rcvd: 26152161
dev.ix.0.mac_stats.good_pkts_rcvd: 26152160
dev.ix.0.mac_stats.bcast_pkts_rcvd: 14
dev.ix.0.mac_stats.rx_frames_64: 7772428
dev.ix.0.mac_stats.rx_frames_65_127: 6873175
dev.ix.0.mac_stats.rx_frames_128_255: 1307100
dev.ix.0.mac_stats.rx_frames_256_511: 357380
dev.ix.0.mac_stats.rx_frames_512_1023: 864763
dev.ix.0.mac_stats.rx_frames_1024_1522: 8977315
dev.ix.0.mac_stats.checksum_errs: 2102613
dev.ix.0.mac_stats.good_octets_txd: 26087412809
dev.ix.0.mac_stats.total_pkts_txd: 26792651
dev.ix.0.mac_stats.good_pkts_txd: 26792651
dev.ix.0.mac_stats.bcast_pkts_txd: 1
dev.ix.0.mac_stats.tx_frames_64: 2599916
dev.ix.0.mac_stats.tx_frames_65_127: 5841901
dev.ix.0.mac_stats.tx_frames_128_255: 819713
dev.ix.0.mac_stats.tx_frames_256_511: 616563
dev.ix.0.mac_stats.tx_frames_512_1023: 375796
dev.ix.0.mac_stats.tx_frames_1024_1522: 16538762

===

Share this post


Link to post
Share on other sites

.checksum_errs: 2102613

 

Это 8% от общего числа принятых пакетов, много.

 

Без NAT'a та же ситуация?

 

Больше не знаю, что подсказать - у меня на стенде Xeon E3-1270 с Intel 82599 влёгкую генерировал 1.6 Mpps (через сервер, увы, не пропускал из-за отсутствия возможности).

 

 

Share this post


Link to post
Share on other sites

Попробуйте в несколько потоков. У меня на 82598 7.5-8 выжимал между серверами iperf ом в несколько потоков. В один похоже проц не может столько сгенерировать...

Share this post


Link to post
Share on other sites

Я генерировал через ng_source. Iperf тоже гонял, вот только результатов не помню :) А десятки уже ушли в сервера виртуализации, так что не потестить.

 

 

Share this post


Link to post
Share on other sites

.checksum_errs: 2102613

 

Это 8% от общего числа принятых пакетов, много.

 

Без NAT'a та же ситуация?

с натом, без ната, с dummynet, без dummynet - CRC ошибки все равно есть, точнее просто счетчик есть, так как пакетлоса нет вообще.

Проверил уже с двумя сетевухами на базе 82599 - с двухголовой и одноголовой (в обоих случаях они с SFP+ SR).

checksum_errs тикает в обоих случаях.

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