Re: Re[2]: ixgbe interface micro stalls / slow responses
Same behaviour with just one queue:- Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ixtest 0.0%280.1 24.4 0.1 297.5 73.0 ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 port 0x2000-0x201f mem 0xd840-0xd847,0xd848-0xd8483fff irq 52 at device 0.0 on pci5 ix0: Using MSIX interrupts with 2 vectors ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:1b:21:7e:2e:8c ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 Setting the following in loader.conf does fix the RX warning, so could do with updating the docs so it lists /boot/loader.conf instead of /etc/sysctl.conf kern.ipc.nmbjumbop=262144 kern.ipc.nmbclusters=524288 Regards Steve - Original Message - From: Jack Vogel To: Steven Hartland Cc: Коньков Евгений ; freebsd-net@freebsd.org Sent: Monday, March 12, 2012 8:32 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses I don't know what to make of it right now, i would suggest going minimal, meaning go to a single queue and see what the behavior is. Jack 2012/3/12 Steven Hartland kill...@multiplay.co.uk Looks like nmbclusters sysctl changes need to loader.conf so they are available early enough for the driver. We haven't rebooted to test that yet as the machine is under so little network load I wouldn't expect raising it from 1024 to 2048 RX descriptors to make any real difference, what do you recon? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
ixgbe interface micro stalls / slow responses
We've got a machine where with an ix interface on 8.2-RELEASE which is seeing intermittent slow responses. It shows as stalls on the console and is visible as high pings on an mtr from a local machine e.g. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. X.X.X.X 0.0% 1810.1 117.7 0.1 2665. 314.8 We've tried updating from 2.3.10 release driver + alias fix to 2.4.5 (the latest from 8.3) but still the behavour is the same. If we do a trace to an igb on the same machine everything is clean. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.10.10.64 0.0% 1360.1 0.2 0.1 12.5 1.1 We are seeing RX Descriptors exceed system mbuf max, using default instead! on boot with the latest driver but the fix listed in the readme has no effect, as in sysctl.conf we have kern.ipc.nmbclusters=524288 kern.ipc.nmbjumbop=262144 Nothing looks out of the ordinary by there's definitely a problem there somewhere, any ideas? Detailed info which may be use below. From dmeg:- ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 port 0x2000-0x201f mem 0xd840-0xd847,0xd848-0xd8483fff irq 52 at device 0.0 on pci5 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:1b:21:7e:2e:8c ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 pciconf -v -l ix0@pci0:5:0:0: class=0x02 card=0x00068086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet sysctl dev.ix dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0006 class=0x02 dev.ix.0.%parent: pci5 dev.ix.0.fc: 3 dev.ix.0.advertise_gig: 0 dev.ix.0.enable_aim: 1 dev.ix.0.advertise_speed: 0 dev.ix.0.rx_processing_limit: 128 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.no_tx_dma_setup: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.tso_tx: 174470 dev.ix.0.link_irq: 3 dev.ix.0.queue0.interrupt_rate: 100 dev.ix.0.queue0.txd_head: 59 dev.ix.0.queue0.txd_tail: 59 dev.ix.0.queue0.no_desc_avail: 0 dev.ix.0.queue0.tx_packets: 38913 dev.ix.0.queue0.rxd_head: 384 dev.ix.0.queue0.rxd_tail: 383 dev.ix.0.queue0.rx_packets: 54982 dev.ix.0.queue0.rx_bytes: 36197485 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 100 dev.ix.0.queue1.txd_head: 1417 dev.ix.0.queue1.txd_tail: 1417 dev.ix.0.queue1.no_desc_avail: 0 dev.ix.0.queue1.tx_packets: 51196 dev.ix.0.queue1.rxd_head: 445 dev.ix.0.queue1.rxd_tail: 444 dev.ix.0.queue1.rx_packets: 70841 dev.ix.0.queue1.rx_bytes: 26319740 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 20408 dev.ix.0.queue2.txd_head: 194 dev.ix.0.queue2.txd_tail: 194 dev.ix.0.queue2.no_desc_avail: 0 dev.ix.0.queue2.tx_packets: 45102 dev.ix.0.queue2.rxd_head: 696 dev.ix.0.queue2.rxd_tail: 695 dev.ix.0.queue2.rx_packets: 65107 dev.ix.0.queue2.rx_bytes: 49222403 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 20 dev.ix.0.queue3.txd_head: 1605 dev.ix.0.queue3.txd_tail: 1605 dev.ix.0.queue3.no_desc_avail: 0 dev.ix.0.queue3.tx_packets: 77375 dev.ix.0.queue3.rxd_head: 79 dev.ix.0.queue3.rxd_tail: 78 dev.ix.0.queue3.rx_packets: 109498 dev.ix.0.queue3.rx_bytes: 109951775 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 10526 dev.ix.0.queue4.txd_head: 1624 dev.ix.0.queue4.txd_tail: 1624 dev.ix.0.queue4.no_desc_avail: 0 dev.ix.0.queue4.tx_packets: 39497 dev.ix.0.queue4.rxd_head: 480 dev.ix.0.queue4.rxd_tail: 479 dev.ix.0.queue4.rx_packets: 51998 dev.ix.0.queue4.rx_bytes: 21965859 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 100 dev.ix.0.queue5.txd_head: 1613 dev.ix.0.queue5.txd_tail: 1613 dev.ix.0.queue5.no_desc_avail: 0 dev.ix.0.queue5.tx_packets: 69860 dev.ix.0.queue5.rxd_head: 846 dev.ix.0.queue5.rxd_tail: 845 dev.ix.0.queue5.rx_packets: 81331 dev.ix.0.queue5.rx_bytes: 32429926 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.queue6.interrupt_rate: 142857 dev.ix.0.queue6.txd_head: 1482 dev.ix.0.queue6.txd_tail: 1484 dev.ix.0.queue6.no_desc_avail: 0 dev.ix.0.queue6.tx_packets: 45878 dev.ix.0.queue6.rxd_head: 355 dev.ix.0.queue6.rxd_tail: 354 dev.ix.0.queue6.rx_packets: 62211 dev.ix.0.queue6.rx_bytes: 27653559 dev.ix.0.queue6.lro_queued: 0 dev.ix.0.queue6.lro_flushed: 0 dev.ix.0.queue7.interrupt_rate: 5347 dev.ix.0.queue7.txd_head: 603 dev.ix.0.queue7.txd_tail: 603 dev.ix.0.queue7.no_desc_avail: 0
Re: ixgbe interface micro stalls / slow responses
As a quick update see below, still stumped on what's causing this but does explain at least two of the other suspect behaviours. - Original Message - From: Steven Hartland We are seeing RX Descriptors exceed system mbuf max, using default instead! on boot with the latest driver but the fix listed in the readme has no effect, as in sysctl.conf we have kern.ipc.nmbclusters=524288 kern.ipc.nmbjumbop=262144 Just been looking at the code and call be stupid but the driver loads before root is mounted and hence before /etc/rc.d/sysctl has run so how can adding values to this possibly work? Is this meant to say /boot/loader.conf? ... A ping from the cisco 6509 its connected to:- Sending 1000, 100-byte ICMP Echos to 85.236.96.64, timeout is 2 seconds: !! !! !. !! !! !. !! !! !!.!!! !! !! !!.!!! !! !! Success rate is 99 percent (996/1000), round-trip min/avg/max = 1/1/208 ms The regular loss here is due to icmp limiting so is not a factor here. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
RE: ixgbe interface micro stalls / slow responses
If you put kern.ipc.nmbclusters=524288 kern.ipc.nmbjumbop=262144 on /boot/loader.conf it won't be ix0: RX Descriptors exceed system mbuf max, using default instead! Seyit Özgür Network Yöneticisi -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On Behalf Of Steven Hartland Sent: Monday, March 12, 2012 5:05 PM To: freebsd-net@freebsd.org Subject: ixgbe interface micro stalls / slow responses We've got a machine where with an ix interface on 8.2-RELEASE which is seeing intermittent slow responses. It shows as stalls on the console and is visible as high pings on an mtr from a local machine e.g. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. X.X.X.X 0.0% 1810.1 117.7 0.1 2665. 314.8 We've tried updating from 2.3.10 release driver + alias fix to 2.4.5 (the latest from 8.3) but still the behavour is the same. If we do a trace to an igb on the same machine everything is clean. Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.10.10.64 0.0% 1360.1 0.2 0.1 12.5 1.1 We are seeing RX Descriptors exceed system mbuf max, using default instead! on boot with the latest driver but the fix listed in the readme has no effect, as in sysctl.conf we have kern.ipc.nmbclusters=524288 kern.ipc.nmbjumbop=262144 Nothing looks out of the ordinary by there's definitely a problem there somewhere, any ideas? Detailed info which may be use below. From dmeg:- ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 port 0x2000-0x201f mem 0xd840-0xd847,0xd848-0xd8483fff irq 52 at device 0.0 on pci5 ix0: Using MSIX interrupts with 9 vectors ix0: RX Descriptors exceed system mbuf max, using default instead! ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: [ITHREAD] ix0: Ethernet address: 00:1b:21:7e:2e:8c ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 pciconf -v -l ix0@pci0:5:0:0: class=0x02 card=0x00068086 chip=0x10fb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet sysctl dev.ix dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 dev.ix.0.%driver: ix dev.ix.0.%location: slot=0 function=0 dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0006 class=0x02 dev.ix.0.%parent: pci5 dev.ix.0.fc: 3 dev.ix.0.advertise_gig: 0 dev.ix.0.enable_aim: 1 dev.ix.0.advertise_speed: 0 dev.ix.0.rx_processing_limit: 128 dev.ix.0.dropped: 0 dev.ix.0.mbuf_defrag_failed: 0 dev.ix.0.no_tx_dma_setup: 0 dev.ix.0.watchdog_events: 0 dev.ix.0.tso_tx: 174470 dev.ix.0.link_irq: 3 dev.ix.0.queue0.interrupt_rate: 100 dev.ix.0.queue0.txd_head: 59 dev.ix.0.queue0.txd_tail: 59 dev.ix.0.queue0.no_desc_avail: 0 dev.ix.0.queue0.tx_packets: 38913 dev.ix.0.queue0.rxd_head: 384 dev.ix.0.queue0.rxd_tail: 383 dev.ix.0.queue0.rx_packets: 54982 dev.ix.0.queue0.rx_bytes: 36197485 dev.ix.0.queue0.lro_queued: 0 dev.ix.0.queue0.lro_flushed: 0 dev.ix.0.queue1.interrupt_rate: 100 dev.ix.0.queue1.txd_head: 1417 dev.ix.0.queue1.txd_tail: 1417 dev.ix.0.queue1.no_desc_avail: 0 dev.ix.0.queue1.tx_packets: 51196 dev.ix.0.queue1.rxd_head: 445 dev.ix.0.queue1.rxd_tail: 444 dev.ix.0.queue1.rx_packets: 70841 dev.ix.0.queue1.rx_bytes: 26319740 dev.ix.0.queue1.lro_queued: 0 dev.ix.0.queue1.lro_flushed: 0 dev.ix.0.queue2.interrupt_rate: 20408 dev.ix.0.queue2.txd_head: 194 dev.ix.0.queue2.txd_tail: 194 dev.ix.0.queue2.no_desc_avail: 0 dev.ix.0.queue2.tx_packets: 45102 dev.ix.0.queue2.rxd_head: 696 dev.ix.0.queue2.rxd_tail: 695 dev.ix.0.queue2.rx_packets: 65107 dev.ix.0.queue2.rx_bytes: 49222403 dev.ix.0.queue2.lro_queued: 0 dev.ix.0.queue2.lro_flushed: 0 dev.ix.0.queue3.interrupt_rate: 20 dev.ix.0.queue3.txd_head: 1605 dev.ix.0.queue3.txd_tail: 1605 dev.ix.0.queue3.no_desc_avail: 0 dev.ix.0.queue3.tx_packets: 77375 dev.ix.0.queue3.rxd_head: 79 dev.ix.0.queue3.rxd_tail: 78 dev.ix.0.queue3.rx_packets: 109498 dev.ix.0.queue3.rx_bytes: 109951775 dev.ix.0.queue3.lro_queued: 0 dev.ix.0.queue3.lro_flushed: 0 dev.ix.0.queue4.interrupt_rate: 10526 dev.ix.0.queue4.txd_head: 1624 dev.ix.0.queue4.txd_tail: 1624 dev.ix.0.queue4.no_desc_avail: 0 dev.ix.0.queue4.tx_packets: 39497 dev.ix.0.queue4.rxd_head: 480 dev.ix.0.queue4.rxd_tail: 479 dev.ix.0.queue4.rx_packets: 51998 dev.ix.0.queue4.rx_bytes: 21965859 dev.ix.0.queue4.lro_queued: 0 dev.ix.0.queue4.lro_flushed: 0 dev.ix.0.queue5.interrupt_rate: 100 dev.ix.0.queue5.txd_head: 1613 dev.ix.0.queue5.txd_tail: 1613 dev.ix.0.queue5.no_desc_avail: 0 dev.ix.0.queue5.tx_packets: 69860 dev.ix.0.queue5.rxd_head: 846 dev.ix.0.queue5.rxd_tail: 845 dev.ix.0.queue5.rx_packets: 81331 dev.ix.0.queue5.rx_bytes: 32429926 dev.ix.0.queue5.lro_queued: 0 dev.ix.0.queue5.lro_flushed: 0 dev.ix.0.queue6.interrupt_rate
Re: ixgbe interface micro stalls / slow responses
Здравствуйте, Steven. Вы писали 12 марта 2012 г., 17:05:12: SH We've got a machine where with an ix interface on 8.2-RELEASE SH which is seeing intermittent slow responses. It shows as stalls SH on the console and is visible as high pings on an mtr SH from a local machine e.g. SH Packets Pings SH Host Loss% Snt Last Avg Best Wrst StDev SH 1. X.X.X.X 0.0% 1810.1 117.7 0.1 2665. 314.8 SH We've tried updating from 2.3.10 release driver + alias fix SH to 2.4.5 (the latest from 8.3) but still the behavour is the SH same. SH If we do a trace to an igb on the same machine everything is SH clean. SH Packets Pings SH Host Loss% Snt Last Avg Best Wrst StDev SH 1. 10.10.10.64 0.0% 1360.1 0.2 0.1 12.5 1.1 SH We are seeing RX Descriptors exceed system mbuf max, using SH default instead! on boot with the latest driver but the fix SH listed in the readme has no effect, as in sysctl.conf we have SH kern.ipc.nmbclusters=524288 SH kern.ipc.nmbjumbop=262144 SH Nothing looks out of the ordinary by there's definitely a SH problem there somewhere, any ideas? SH Detailed info which may be use below. From dmeg:- SH ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 port 0x2000-0x201f mem SH 0xd840-0xd847,0xd848-0xd8483fff irq 52 at device 0.0 on pci5 SH ix0: Using MSIX interrupts with 9 vectors SH ix0: RX Descriptors exceed system mbuf max, using default instead! SH ix0: [ITHREAD] SH ix0: [ITHREAD] SH ix0: [ITHREAD] SH ix0: [ITHREAD] SH ix0: [ITHREAD] SH ix0: [ITHREAD] SH ix0: [ITHREAD] SH ix0: [ITHREAD] SH ix0: [ITHREAD] SH ix0: Ethernet address: 00:1b:21:7e:2e:8c SH ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 SH pciconf -v -l SH ix0@pci0:5:0:0: class=0x02 card=0x00068086 chip=0x10fb8086 rev=0x01 hdr=0x00 SH vendor = 'Intel Corporation' SH class = network SH subclass = ethernet SH sysctl dev.ix SH dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.4.5 SH dev.ix.0.%driver: ix SH dev.ix.0.%location: slot=0 function=0 SH dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x0006 class=0x02 SH dev.ix.0.%parent: pci5 SH dev.ix.0.fc: 3 SH dev.ix.0.advertise_gig: 0 SH dev.ix.0.enable_aim: 1 SH dev.ix.0.advertise_speed: 0 SH dev.ix.0.rx_processing_limit: 128 SH dev.ix.0.dropped: 0 SH dev.ix.0.mbuf_defrag_failed: 0 SH dev.ix.0.no_tx_dma_setup: 0 SH dev.ix.0.watchdog_events: 0 SH dev.ix.0.tso_tx: 174470 SH dev.ix.0.link_irq: 3 SH dev.ix.0.queue0.interrupt_rate: 100 SH dev.ix.0.queue0.txd_head: 59 SH dev.ix.0.queue0.txd_tail: 59 SH dev.ix.0.queue0.no_desc_avail: 0 SH dev.ix.0.queue0.tx_packets: 38913 SH dev.ix.0.queue0.rxd_head: 384 SH dev.ix.0.queue0.rxd_tail: 383 SH dev.ix.0.queue0.rx_packets: 54982 SH dev.ix.0.queue0.rx_bytes: 36197485 SH dev.ix.0.queue0.lro_queued: 0 SH dev.ix.0.queue0.lro_flushed: 0 SH dev.ix.0.queue1.interrupt_rate: 100 SH dev.ix.0.queue1.txd_head: 1417 SH dev.ix.0.queue1.txd_tail: 1417 SH dev.ix.0.queue1.no_desc_avail: 0 SH dev.ix.0.queue1.tx_packets: 51196 SH dev.ix.0.queue1.rxd_head: 445 SH dev.ix.0.queue1.rxd_tail: 444 SH dev.ix.0.queue1.rx_packets: 70841 SH dev.ix.0.queue1.rx_bytes: 26319740 SH dev.ix.0.queue1.lro_queued: 0 SH dev.ix.0.queue1.lro_flushed: 0 SH dev.ix.0.queue2.interrupt_rate: 20408 SH dev.ix.0.queue2.txd_head: 194 SH dev.ix.0.queue2.txd_tail: 194 SH dev.ix.0.queue2.no_desc_avail: 0 SH dev.ix.0.queue2.tx_packets: 45102 SH dev.ix.0.queue2.rxd_head: 696 SH dev.ix.0.queue2.rxd_tail: 695 SH dev.ix.0.queue2.rx_packets: 65107 SH dev.ix.0.queue2.rx_bytes: 49222403 SH dev.ix.0.queue2.lro_queued: 0 SH dev.ix.0.queue2.lro_flushed: 0 SH dev.ix.0.queue3.interrupt_rate: 20 SH dev.ix.0.queue3.txd_head: 1605 SH dev.ix.0.queue3.txd_tail: 1605 SH dev.ix.0.queue3.no_desc_avail: 0 SH dev.ix.0.queue3.tx_packets: 77375 SH dev.ix.0.queue3.rxd_head: 79 SH dev.ix.0.queue3.rxd_tail: 78 SH dev.ix.0.queue3.rx_packets: 109498 SH dev.ix.0.queue3.rx_bytes: 109951775 SH dev.ix.0.queue3.lro_queued: 0 SH dev.ix.0.queue3.lro_flushed: 0 SH dev.ix.0.queue4.interrupt_rate: 10526 SH dev.ix.0.queue4.txd_head: 1624 SH dev.ix.0.queue4.txd_tail: 1624 SH dev.ix.0.queue4.no_desc_avail: 0 SH dev.ix.0.queue4.tx_packets: 39497 SH dev.ix.0.queue4.rxd_head: 480 SH dev.ix.0.queue4.rxd_tail: 479 SH dev.ix.0.queue4.rx_packets: 51998 SH dev.ix.0.queue4.rx_bytes: 21965859 SH dev.ix.0.queue4.lro_queued: 0 SH dev.ix.0.queue4.lro_flushed: 0 SH dev.ix.0.queue5.interrupt_rate: 100 SH dev.ix.0.queue5.txd_head: 1613 SH dev.ix.0.queue5.txd_tail: 1613 SH dev.ix.0.queue5.no_desc_avail: 0 SH dev.ix.0.queue5.tx_packets: 69860 SH dev.ix.0.queue5.rxd_head: 846 SH dev.ix.0.queue5.rxd_tail: 845 SH dev.ix.0.queue5.rx_packets: 81331 SH dev.ix.0.queue5.rx_bytes: 32429926 SH dev.ix.0.queue5.lro_queued: 0 SH dev.ix.0.queue5.lro_flushed: 0 SH dev.ix.0.queue6.interrupt_rate: 142857 SH
Re: ixgbe interface micro stalls / slow responses
- Original Message - From: Коньков Евгений kes-...@yandex.ru Apparently not:- can you show netstat -Q ? netstat -Q netstat: illegal option -- Q This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re[2]: ixgbe interface micro stalls / slow responses
can you show netstat -Q ? netstat -Q SH netstat: illegal option -- Q uname -a ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Re[2]: ixgbe interface micro stalls / slow responses
- Original Message - From: Коньков Евгений kes-...@yandex.ru To: Steven Hartland kill...@multiplay.co.uk Cc: freebsd-net@freebsd.org Sent: Monday, March 12, 2012 6:21 PM Subject: Re[2]: ixgbe interface micro stalls / slow responses can you show netstat -Q ? netstat -Q SH netstat: illegal option -- Q uname -a As mentioned 8.2-RELEASE specifically -p6 with a few additional local patches. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Re[2]: ixgbe interface micro stalls / slow responses
Well, first thing to do is try the latest code, which is now in the 8.3 stream. Jack 2012/3/12 Steven Hartland kill...@multiplay.co.uk - Original Message - From: Коньков Евгений kes-...@yandex.ru To: Steven Hartland kill...@multiplay.co.uk Cc: freebsd-net@freebsd.org Sent: Monday, March 12, 2012 6:21 PM Subject: Re[2]: ixgbe interface micro stalls / slow responses can you show netstat -Q ? netstat -Q SH netstat: illegal option -- Q uname -a As mentioned 8.2-RELEASE specifically -p6 with a few additional local patches. Regards Steve ==**== This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. __**_ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-nethttp://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscribe@**freebsd.orgfreebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Re[2]: ixgbe interface micro stalls / slow responses
If your referring to driver code, as mentioned in my initial post, already tried that, no change :( - Original Message - From: Jack Vogel To: Steven Hartland Cc: Коньков Евгений ; freebsd-net@freebsd.org Sent: Monday, March 12, 2012 7:14 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses Well, first thing to do is try the latest code, which is now in the 8.3 stream. Jack This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Re[2]: ixgbe interface micro stalls / slow responses
Have you gotten rid of the rx descriptors exceeded problem? Jack 2012/3/12 Steven Hartland kill...@multiplay.co.uk ** If your referring to driver code, as mentioned in my initial post, already tried that, no change :( - Original Message - *From:* Jack Vogel jfvo...@gmail.com *To:* Steven Hartland kill...@multiplay.co.uk *Cc:* Коньков Евгений kes-...@yandex.ru ; freebsd-net@freebsd.org *Sent:* Monday, March 12, 2012 7:14 PM *Subject:* Re: Re[2]: ixgbe interface micro stalls / slow responses Well, first thing to do is try the latest code, which is now in the 8.3 stream. Jack This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Re[2]: ixgbe interface micro stalls / slow responses
Looks like nmbclusters sysctl changes need to loader.conf so they are available early enough for the driver. We haven't rebooted to test that yet as the machine is under so little network load I wouldn't expect raising it from 1024 to 2048 RX descriptors to make any real difference, what do you recon? Regards Steve - Original Message - From: Jack Vogel To: Steven Hartland Cc: Коньков Евгений ; freebsd-net@freebsd.org Sent: Monday, March 12, 2012 8:11 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses Have you gotten rid of the rx descriptors exceeded problem? This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Re[2]: ixgbe interface micro stalls / slow responses
I don't know what to make of it right now, i would suggest going minimal, meaning go to a single queue and see what the behavior is. Jack 2012/3/12 Steven Hartland kill...@multiplay.co.uk ** Looks like nmbclusters sysctl changes need to loader.conf so they are available early enough for the driver. We haven't rebooted to test that yet as the machine is under so little network load I wouldn't expect raising it from 1024 to 2048 RX descriptors to make any real difference, what do you recon? Regards Steve - Original Message - *From:* Jack Vogel jfvo...@gmail.com *To:* Steven Hartland kill...@multiplay.co.uk *Cc:* Коньков Евгений kes-...@yandex.ru ; freebsd-net@freebsd.org *Sent:* Monday, March 12, 2012 8:11 PM *Subject:* Re: Re[2]: ixgbe interface micro stalls / slow responses Have you gotten rid of the rx descriptors exceeded problem? This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Re[2]: ixgbe interface micro stalls / slow responses
Will give that a go tomorrow morning thanks :) Regards Steve - Original Message - From: Jack Vogel To: Steven Hartland Cc: Коньков Евгений ; freebsd-net@freebsd.org Sent: Monday, March 12, 2012 8:32 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses I don't know what to make of it right now, i would suggest going minimal, meaning go to a single queue and see what the behavior is. Jack 2012/3/12 Steven Hartland kill...@multiplay.co.uk Looks like nmbclusters sysctl changes need to loader.conf so they are available early enough for the driver. We haven't rebooted to test that yet as the machine is under so little network load I wouldn't expect raising it from 1024 to 2048 RX descriptors to make any real difference, what do you recon? Regards Steve - Original Message - From: Jack Vogel To: Steven Hartland Cc: Коньков Евгений ; freebsd-net@freebsd.org Sent: Monday, March 12, 2012 8:11 PM Subject: Re: Re[2]: ixgbe interface micro stalls / slow responses Have you gotten rid of the rx descriptors exceeded problem? This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
