Date: Wed, 1 Oct 2014 09:39:54 +0900 From: Yonghyeon PYUN <pyunyh@gmail.com> To: Nils Beyer <nbe@renzel.net> Cc: freebsd-net@freebsd.org Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20141001003954.GA2632@michelle.fasterthan.com> In-Reply-To: <20140930093516.80A8943F@hub.freebsd.org> References: <20140930015741.GA2451@michelle.fasterthan.com> <20140930082053.4D9EFF8F@hub.freebsd.org> <20140930085228.GB969@michelle.fasterthan.com> <20140930093516.80A8943F@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 30, 2014 at 11:35:03AM +0200, Nils Beyer wrote:
> Hi,
>
> Yonghyeon PYUN wrote:
> >> Then I've connected a network cable and rebooted. I've got a link and
> >> performed an "iperf" test. The results are really good: around 930 Mbit/s
> >> TX and 840 Mbit/s RX. CPU load during that test: "70.75% kernel{alc0
> >> taskq}".
> >
> > Hmm, the RX performance number looks bad to me. You have to see
> > more than 920Mbps.
>
> You're right; my fault - sorry for that. The "iperf partner" seems to have a
> bad/weak NIC because it also only gets 840 Mbit/s sending to another computer.
> So I've exchanged the "iperf partner" with another computer and am getting now
> 935 Mbit/s in both directions.
>
Ok, thanks for letting me know that. If you use jumbo frame you
would get better performance numbers.
> I should always measure measuring equipment before measuring.
>
Default interrupt moderation policy is targeted to reduce latency
so it will generate up to 10k interrupts/sec under high network
load. If you want to reduce number of interrupts/sec, tune
interrupt moderation sysctl variables mentioned in alc(4).
>
> > Could you show me the output of "pciconf -lcbv"?
>
> Probably not neccessary anymore, but here you are (with additional -e option):
> -------------------------------------------------------------------------------
> #pciconf -lcbve | tail -20
> alc0@pci0:2:0:0: class=0x020000 card=0x05621028 chip=0x10911969 rev=0x10 hdr=0x00
> vendor = 'Atheros Communications Inc.'
> device = 'AR8161 Gigabit Ethernet'
> class = network
> subclass = ethernet
> bar [10] = type Memory, range 64, base 0xd0400000, size 262144, enabled
> bar [18] = type I/O Port, range 32, base 0x2000, size 128, enabled
> cap 01[40] = powerspec 3 supports D0 D3 current D0
> cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1)
> speed 2.5(2.5) ASPM L1(L0s/L1)
> cap 05[c0] = MSI supports 16 messages, 64 bit, vector masks
> cap 11[d8] = MSI-X supports 16 messages, enabled
> Table in map 0x10[0x2000], PBA in map 0x10[0x3000]
> ecap 0001[100] = AER 1 0 fatal 1 non-fatal 1 corrected
> ecap 0003[180] = Serial 1 ff55c9fb5cf9ddff
> PCI-e errors = Correctable Error Detected
> Non-Fatal Error Detected
> Unsupported Request Detected
> Non-fatal = Unsupported Request
> Corrected = Bad DLLP
> -------------------------------------------------------------------------------
Thanks for the info.
>
>
> > I thought I verified link lost condition before requesting test.
> > After reading your mail, I was successfully reproduce it with
> > engineering sample board. It seems when link lost time lasts long
> > enough alc(4) fails to re-establish a link.
>
> Confirmed - if the network cable is disconnected long enough I cannot get a
> link either. As a workaround I un- and reload the "if_alc" module; then
> everything is working again as before...
>
Updated the diff to address link establishment issue.
http://people.freebsd.org/~yongari/alc/pci.quirk.diff
http://people.freebsd.org/~yongari/alc/alc.diff.20141001
Thanks.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141001003954.GA2632>