[CFT] alc(4) QAC AR816x/AR817x ethernet controller support

[Yonghyeon PYUN]

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 at 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.