From owner-freebsd-net@FreeBSD.ORG Fri Nov 11 23:57:32 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE94106566B for ; Fri, 11 Nov 2011 23:57:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC85E8FC0C for ; Fri, 11 Nov 2011 23:57:31 +0000 (UTC) Received: by ggnk3 with SMTP id k3so6697578ggn.13 for ; Fri, 11 Nov 2011 15:57:31 -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=u2liqGa7uA4no5WQRcxAgCp/0mKNjVL+4MTLyL4nUvM=; b=K1vEW7rF6AKsmTXnW5SiNkly/1AoQ3wh+CyETwIYcgKFJdBfW1MPaA/iqywkkp30YP GRtMQeX4vED43Zm7+FhjEaGamO9loq0wq9Zf9yO8hYAkmstmLcvHX5z750aV2GZpeufn RFAyWaAqF/zHXD1lC+MVAHEKJLoP88qBUbvG0= Received: by 10.68.4.200 with SMTP id m8mr28141754pbm.50.1321055850699; Fri, 11 Nov 2011 15:57:30 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id lk8sm33926390pbb.4.2011.11.11.15.57.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 15:57:29 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 11 Nov 2011 15:55:26 -0800 From: YongHyeon PYUN Date: Fri, 11 Nov 2011 15:55:26 -0800 To: Michael =?iso-8859-1?B?TGHf?= Message-ID: <20111111235526.GC17792@michelle.cdnetworks.com> References: <1320494003.19667.41.camel@bevan-pc.fritz.box> <20111106234054.GB1906@michelle.cdnetworks.com> <20111107175953.GA1646@michelle.cdnetworks.com> <1321046480.8512.3.camel@bevan-pc.fritz.box> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <1321046480.8512.3.camel@bevan-pc.fritz.box> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Gigabit Ethernet performance with Realtek 8111E 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, 11 Nov 2011 23:57:32 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 11, 2011 at 10:21:20PM +0100, Michael La?? wrote: > Hi! > > Sorry for my late response. > > Am Montag, den 07.11.2011, 09:59 -0800 schrieb YongHyeon PYUN: > > > > > > Some revisions of RealTek controller have FIFO overrun issue but > > > I'm not sure whether you're seeing the issue. Try enabling flow > > > control and see whether that makes any difference. You can enable > > > it by issuing 'ifconfig re0 media flow'. > > > > This should be read as 'ifconfig re0 mediaopt flow'. > > It may be that enabling flow control helps a bit but it definately does > not solve the problem. There are still hundreds of packets missed in > just one or two minutes. Maybe there is no difference at all. > Ok, try attached patch and let me know how it works. > > > Show me the dmesg output. RealTek uses the same device PCI ids so it's > > > impossible to know which controller you have from the pciconf(8) > > > output. > > I think the relevant part is this one: > > re0: port 0x1000-0x10ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 16 at device 0.0 on pci1 > > re0: Using 1 MSI-X message > > re0: Chip rev. 0x2c000000 > > re0: MAC rev. 0x00000000 > > miibus0: on re0 > > rgephy0: PHY 1 on miibus0 > > 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 > > re0: Ethernet address: 38:60:77:3e:af:a5 > Your controller is RTL8168E. > Full dmesg output is also attached. > > Greetings, > Michael > > PS: In my first mail I wrote that I can reproduce the problem only with > one of two connected hosts. I think the reason is that the other host > only produces a maximum of 250Mbit/s while the problematic transfers go > up to 550Mbit/s. --vtzGhvizbBRQ85DL Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="re.oflow.diff" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 227451) +++ sys/dev/re/if_re.c (working copy) @@ -2524,6 +2524,8 @@ intrs = RL_INTRS_CPLUS; status = CSR_READ_2(sc, RL_ISR); + if ((status & RL_ISR_FIFO_OFLOW) != 0) + status |= RL_ISR_RX_OVERRUN; CSR_WRITE_2(sc, RL_ISR, status); if (sc->rl_int_rx_act > 0) { intrs &= ~(RL_ISR_RX_OK | RL_ISR_RX_ERR | RL_ISR_FIFO_OFLOW | --vtzGhvizbBRQ85DL--