From owner-freebsd-net@FreeBSD.ORG Wed Oct 1 00:40:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6754C896 for ; Wed, 1 Oct 2014 00:40:04 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3AA18C8E for ; Wed, 1 Oct 2014 00:40:04 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kq14so82783pab.40 for ; Tue, 30 Sep 2014 17:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0K8gjTXjHrYOkYMF0YiPboHeUmuXrWmHI82xzs71na0=; b=i9rD0xMql9AkaUohNQUeMpAQ7IWmmgwqApHgksvV7UcyuFOcBgml33238Z4klOYKRC IH5GXvHoKNtxMgQIJWZVvLSttV6GXJu0Vvc4YB/URzERaF8ZRZIwyNedVKavelbM44oM xtOlCP0QUXQODhip0ugAS+XjfSPIzxm9J3ykHjnIsV1Yd78Cy4iMwIA1X4Ndpv89OoBI 8Zm01LMLu9UIzX6tbc+kwGZeawkkcCu3RGtjcvPJ0wKwy5ipfxgeO9uzD5s7LhKVRnpG N5xwbf9D8XgNqumsFvaziIzYBfAcq9vB6+h8Fw0yDrmYVOQOooPJGyu+F+QfxZ81h8RW SniQ== X-Received: by 10.70.126.41 with SMTP id mv9mr79697263pdb.129.1412124003809; Tue, 30 Sep 2014 17:40:03 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id fn4sm16335770pab.39.2014.09.30.17.39.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Sep 2014 17:40:02 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 01 Oct 2014 09:39:54 +0900 Date: Wed, 1 Oct 2014 09:39:54 +0900 To: Nils Beyer Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20141001003954.GA2632@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20140930015741.GA2451@michelle.fasterthan.com> <20140930082053.4D9EFF8F@hub.freebsd.org> <20140930085228.GB969@michelle.fasterthan.com> <20140930093516.80A8943F@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140930093516.80A8943F@hub.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 00:40:04 -0000 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.