From owner-freebsd-net@FreeBSD.ORG Fri Jan 13 23:27:21 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6298F1065670 for ; Fri, 13 Jan 2012 23:27:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 264748FC08 for ; Fri, 13 Jan 2012 23:27:20 +0000 (UTC) Received: by obbta17 with SMTP id ta17so4316181obb.13 for ; Fri, 13 Jan 2012 15:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=WPvLup8XP5Xj1SZ0wWEEW1fJ/vYfG6UNtFTGVUXLH8o=; b=hh9k6xxTiG32reG3yuHbCiQ88x0DbTVUqpECrw2kNFaewDSl/CRX0hvYbvRWG69eks Lk6IS/OeyQ/zGvDEodv6w4RZeLmHn9iAYdSu7by07e7947ZMru7NxS6WAl4pnmJeii8T AaN0ZI/noqhzq9SUqoQYuPWMYMgGhZVAREusQ= Received: by 10.50.192.162 with SMTP id hh2mr323182igc.8.1326497240145; Fri, 13 Jan 2012 15:27:20 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q30sm33917617ibc.1.2012.01.13.15.27.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 15:27:19 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 13 Jan 2012 15:27:18 -0800 From: YongHyeon PYUN Date: Fri, 13 Jan 2012 15:27:18 -0800 To: "Vladislav V. Prodan" Message-ID: <20120113232718.GC18199@michelle.cdnetworks.com> References: <4F109F79.5090406@ukr.net> <20120113221548.GA18199@michelle.cdnetworks.com> <4F10B1B3.6090908@ukr.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline In-Reply-To: <4F10B1B3.6090908@ukr.net> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org Subject: Re: Lack of performance re0 (RTL8111/8168B) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 23:27:21 -0000 --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 14, 2012 at 12:35:31AM +0200, Vladislav V. Prodan wrote: > 14.01.2012 0:15, YongHyeon PYUN wrote: > > On Fri, Jan 13, 2012 at 11:17:45PM +0200, Vladislav V. Prodan wrote: > >> > >> Tell me, what a performance in pps a network card RTL8111/8168B? > >> Can I somehow increase it? > >> Experimentally, since it begins to fall off 80Kpps: ( > >> > > > > RX performance number will show much better than that but TX is > > major bottleneck of controller. I tried hard to enhance TX > > performance for the controller but I'm under the impression that > > that number would be the maximum(around 90Kpps) and this is also > > similar number what I got on Linux. > > Given that re(4) controllers are for non-server grade systems I > > wouldn't be surprised to see that number. If you need higher pps, > > choose controllers targeted for servers. Alternatively, low cost > > controllers from JMicron/Atheros also show decent TX/RX > > performance numbers. > > That's why I would like to get some numerical limitations of the > controller re (4). > While there is no way to put a network card from Intel. > > > > >> > >> Jan 13 18:12:49 XXX kernel: re0: watchdog timeout > >> Jan 13 18:12:49 XXX kernel: re0: link state changed to DOWN > >> Jan 13 18:12:53 XXX kernel: re0: link state changed to UP > >> > > > > I'm more concerned on watchdog timeouts than performance numbers. > > Would you show me re(4) related message from dmesg(8) output? > See dmesg output below. > > > And if you know how to reliably trigger the watchdog timeout, would > > you share with us? > > DDoS attack has undergone server and choked these packages: ( Sound like hard to reproduce this on my box. > Trafshow showed a peak of 110K pps, but immediately operational watchdog > timeout. > I would appreciate help in setting up a network interface, so as long as > it is not turned off by such scams. > > >> > >> > >> # uname -a > >> FreeBSD pvppw.org 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #1: Mon Dec 5 > >> 14:56:07 EET 2011 root@XXX:/usr/obj/usr/src/sys/XXX.2 amd64 > >> > >> # pciconf -lv | grep -A 4 "re0@" > >> re0@pci0:2:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06 > >> hdr=0x00 > >> vendor = 'Realtek Semiconductor Co., Ltd.' > >> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > >> class = network > >> subclass = ethernet > >> > > > > RealTek controllers tend to use the same PCI id for different > > controllers so pciconf(8) does not help here. re(4) may have shown > > more details on your controller in dmesg output. > > > Jan 13 18:57:03 XXX kernel: re0: Gigabit Ethernet> port 0xe800-0xe8ff mem > 0xfcfff000-0xfcffffff,0xfcffffff,0xfcff8000-0xfcffbfff irq 18 at device > 0.0 on pci2 > Jan 13 18:57:03 XXX kernel: re0: Using 1 MSI-X message > Jan 13 18:57:03 XXX kernel: re0: Chip rev. 0x2c800000 > Jan 13 18:57:03 XXX kernel: re0: MAC rev. 0x00000000 > Jan 13 18:57:03 XXX kernel: miibus0: on re0 > Jan 13 18:57:03 XXX kernel: rgephy0: media interface> PHY 1 on miibus0 > Jan 13 18:57:03 XXX kernel: rgephy0: none, 10baseT, 10baseT-FDX, > 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, > 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > Jan 13 18:57:03 XXX kernel: re0: Ethernet address: 14:da:e9:75:5f:ee > Thanks, your controller is RTL8168E-VL. Could you try attached patch? The patch also contains unrelated one for the issue but it wouldn't hurt either. --rJwd6BRFiFCcLxzm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.txfifo.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 230063) +++ sys/dev/re/if_re.c (working copy) @@ -3147,7 +3147,13 @@ } else CSR_WRITE_4(sc, RL_TXCFG, RL_TXCFG_CONFIG); - CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16); + /* XXX */ + if ((sc->rl_flags & RL_FLAG_CMDSTOP_WAIT_TXQ) != 0) { + CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 4992 / 128); + CSR_WRITE_4(sc, RL_TXCFG, CSR_READ_4(sc, RL_TXCFG) | + RL_TXCFG_AUTO_FIFO); + } else + CSR_WRITE_1(sc, RL_EARLY_TX_THRESH, 16); /* * Set the initial RX configuration. @@ -3558,7 +3564,6 @@ } /* Free the TX list buffers. */ - for (i = 0; i < sc->rl_ldata.rl_tx_desc_cnt; i++) { txd = &sc->rl_ldata.rl_tx_desc[i]; if (txd->tx_m != NULL) { @@ -3572,11 +3577,10 @@ } /* Free the RX list buffers. */ - for (i = 0; i < sc->rl_ldata.rl_rx_desc_cnt; i++) { rxd = &sc->rl_ldata.rl_rx_desc[i]; if (rxd->rx_m != NULL) { - bus_dmamap_sync(sc->rl_ldata.rl_tx_mtag, + bus_dmamap_sync(sc->rl_ldata.rl_rx_mtag, rxd->rx_dmamap, BUS_DMASYNC_POSTREAD); bus_dmamap_unload(sc->rl_ldata.rl_rx_mtag, rxd->rx_dmamap); @@ -3584,6 +3588,20 @@ rxd->rx_m = NULL; } } + + if ((sc->rl_flags & RL_FLAG_JUMBOV2) != 0) { + for (i = 0; i < sc->rl_ldata.rl_rx_desc_cnt; i++) { + rxd = &sc->rl_ldata.rl_jrx_desc[i]; + if (rxd->rx_m != NULL) { + bus_dmamap_sync(sc->rl_ldata.rl_jrx_mtag, + rxd->rx_dmamap, BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(sc->rl_ldata.rl_jrx_mtag, + rxd->rx_dmamap); + m_freem(rxd->rx_m); + rxd->rx_m = NULL; + } + } + } } /* Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 230063) +++ sys/pci/if_rlreg.h (working copy) @@ -142,6 +142,7 @@ * TX config register bits */ #define RL_TXCFG_CLRABRT 0x00000001 /* retransmit aborted pkt */ +#define RL_TXCFG_AUTO_FIFO 0x00000080 /* 8168E-VL or higher */ #define RL_TXCFG_MAXDMA 0x00000700 /* max DMA burst size */ #define RL_TXCFG_QUEUE_EMPTY 0x00000800 /* 8168E-VL or higher */ #define RL_TXCFG_CRCAPPEND 0x00010000 /* CRC append (0 = yes) */ --rJwd6BRFiFCcLxzm--