From owner-freebsd-arm@FreeBSD.ORG Sun Sep 27 20:04:29 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956411065672 for ; Sun, 27 Sep 2009 20:04:29 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by mx1.freebsd.org (Postfix) with ESMTP id 2AE2B8FC14 for ; Sun, 27 Sep 2009 20:04:28 +0000 (UTC) Received: by ewy5 with SMTP id 5so2372390ewy.36 for ; Sun, 27 Sep 2009 13:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:from :content-type:message-id:date:to:content-transfer-encoding :mime-version:x-mailer; bh=GwAxen+JjSWYpSxIimGRQ8R6h38g7PzuuuWMrfNG/lM=; b=vbtt6Q7IFbMFvxd7Toa3pJO1VsZdxRXl48iAZyMezNVID0SFrsWLuqU2d2zy78Khkp spik3l0jaT8zq54SJVVrKv3OTGlKT4TKbrkSHPoJowtM/KO/S7A9jA6wHZVWocw7j3mO 1x+Jm3sOaOLpSthU1gFBj2K/NJHVibrVOtdWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version:x-mailer; b=a3WeH4w765gqWyo5XXxHBxzJT+zhV/g7IZaCE6XBYSBENfFffzHV+fClS/p+4WGWdX 0UIe0+HUKQ62Lzz8Za/XFim0ABdWGKreOSX6d0dxT1DLfEizxE0pIVanoj8els0vGyGC fEwThcD4xQiRMHUSwE8dkk2Wt77qfI3qoOwQU= Received: by 10.211.171.6 with SMTP id y6mr2134391ebo.91.1254081868084; Sun, 27 Sep 2009 13:04:28 -0700 (PDT) Received: from rui-macbook.lan ([83.144.140.21]) by mx.google.com with ESMTPS id 7sm173315eyg.17.2009.09.27.13.04.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Sep 2009 13:04:27 -0700 (PDT) Sender: Rui Paulo From: Rui Paulo Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <339C618A-08A1-4BE1-BD1C-DBB82B1393D9@FreeBSD.org> Date: Sun, 27 Sep 2009 21:04:26 +0100 To: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: XScale PMC X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 20:04:29 -0000 Looking at the arm code, I noticed that we have the PMC stuff from NetBSD, but we don't use it. NetBSD has XScale PMC support but we haven't ported it yet. In any case, I plan to port the NetBSD code to our hwpmc, so we can remove NetBSD PMC defines. See http://people.freebsd.org/~rpaulo/xscalepmc.diff for what I'm trying to accomplish. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sun Sep 27 22:10:25 2009 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A9F2106568B; Sun, 27 Sep 2009 22:10:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2FD8FC1E; Sun, 27 Sep 2009 22:10:25 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n8RMAOBR042141; Sun, 27 Sep 2009 18:10:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n8RMAOnD042132; Sun, 27 Sep 2009 22:10:24 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 27 Sep 2009 22:10:24 GMT Message-Id: <200909272210.n8RMAOnD042132@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 22:10:25 -0000 TB --- 2009-09-27 21:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-27 21:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-09-27 21:50:00 - cleaning the object tree TB --- 2009-09-27 21:53:08 - cvsupping the source tree TB --- 2009-09-27 21:53:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-09-27 21:55:49 - building world TB --- 2009-09-27 21:55:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-27 21:55:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-27 21:55:49 - TARGET=arm TB --- 2009-09-27 21:55:49 - TARGET_ARCH=arm TB --- 2009-09-27 21:55:49 - TZ=UTC TB --- 2009-09-27 21:55:49 - __MAKE_CONF=/dev/null TB --- 2009-09-27 21:55:49 - cd /src TB --- 2009-09-27 21:55:49 - /usr/bin/make -B buildworld >>> World build started on Sun Sep 27 21:55:52 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] sh /src/tools/install.sh -o root -g wheel -m 444 ca_ES.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/ca_ES.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 de_DE.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/de_DE.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 el_GR.ISO8859-7.cat /obj/arm/src/tmp/usr/share/nls/el_GR.ISO8859-7/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 es_ES.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/es_ES.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 fi_FI.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/fi_FI.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 fr_FR.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/fr_FR.ISO8859-1/libc.cat sh /src/tools/install.sh -o root -g wheel -m 444 gl_ES.ISO8859-1.cat /obj/arm/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat install: /obj/arm/src/tmp/usr/share/nls/gl_ES.ISO8859-1/libc.cat: No such file or directory *** Error code 71 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-27 22:10:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-27 22:10:24 - ERROR: failed to build world TB --- 2009-09-27 22:10:24 - 459.07 user 103.38 system 1224.21 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Sep 28 11:06:50 2009 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6BA1106566B for ; Mon, 28 Sep 2009 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3C968FC19 for ; Mon, 28 Sep 2009 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n8SB6oS3063936 for ; Mon, 28 Sep 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n8SB6oFh063932 for freebsd-arm@FreeBSD.org; Mon, 28 Sep 2009 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Sep 2009 11:06:50 GMT Message-Id: <200909281106.n8SB6oFh063932@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 o arm/134338 arm [patch] Lock GPIO accesses on ixp425 o arm/134092 arm [patch] NSLU.hints contains wrong hints for on board n 3 problems total. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 2 06:13:57 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 157F01065672 for ; Fri, 2 Oct 2009 06:13:57 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id C96648FC12 for ; Fri, 2 Oct 2009 06:13:56 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 531474899E for ; Fri, 2 Oct 2009 07:13:55 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRA2XaNPD8q0 for ; Fri, 2 Oct 2009 07:13:45 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 9993948881 for ; Fri, 2 Oct 2009 07:13:44 +0100 (BST) Message-ID: <4AC599FC.1070304@tomjudge.com> Date: Fri, 02 Oct 2009 06:13:16 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary="------------040000000209090109080707" Subject: [patch] Compilation problems in sys/arm/arm/pmap.c when PMAP_DEBUG is defined. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 06:13:57 -0000 This is a multi-part message in MIME format. --------------040000000209090109080707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I ran into some issues this evening while I was building some kernels with PMAP_DEBUG defined. I have attached a patch that addresses the problems with the DPRINTF sections. (The first 2 hunks should probably be ignored). However there are 2 warnings about unused functions when PMAP_INLINE is defined as "". I did not know what the correct fix for this was so I defined PMAP_INLINE to __inline even when PMAP_DEBUG was set, which seemed to hide the problem again. Tom --------------040000000209090109080707 Content-Type: text/plain; name="pmap.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pmap.patch" Index: sys/arm/arm/pmap.c =================================================================== --- sys/arm/arm/pmap.c (revision 197472) +++ sys/arm/arm/pmap.c (working copy) @@ -142,6 +142,7 @@ * Special compilation symbols * PMAP_DEBUG - Build in pmap_debug_level code */ +#define PMAP_DEBUG /* Include header files */ #include "opt_vm.h" @@ -183,8 +184,9 @@ ((_stat_)) #define dprintf printf -int pmap_debug_level = 0; -#define PMAP_INLINE +int pmap_debug_level = 1; +#define PMAP_INLINE __inline +//#define PMAP_INLINE #else /* PMAP_DEBUG */ #define PDEBUG(_lev_,_stat_) /* Nothing */ #define dprintf(x, arg...) @@ -1914,7 +1916,7 @@ { int shpgperproc = PMAP_SHPGPERPROC; - PDEBUG(1, printf("pmap_init: phys_start = %08x\n")); + PDEBUG(1, printf("pmap_init: phys_start = %08x\n",PHYSADDR )); /* * init the pv free list @@ -2373,8 +2375,8 @@ vm_size_t size; int l1idx, l2idx, l2next = 0; - PDEBUG(1, printf("firstaddr = %08x, loadaddr = %08x\n", - firstaddr, loadaddr)); + PDEBUG(1, printf("firstaddr = %08x, lastaddr = %08x\n", + firstaddr, lastaddr)); virtual_avail = firstaddr; kernel_pmap->pm_l1 = l1; --------------040000000209090109080707-- From owner-freebsd-arm@FreeBSD.ORG Fri Oct 2 06:28:27 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BCDA1065670; Fri, 2 Oct 2009 06:28:27 +0000 (UTC) (envelope-from yohanes@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id AEB128FC0C; Fri, 2 Oct 2009 06:28:26 +0000 (UTC) Received: by gxk6 with SMTP id 6so1062357gxk.13 for ; Thu, 01 Oct 2009 23:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type; bh=tz/1gQywM1pqPBoQ5j+CbA/RPug54SrMz8C4loChwGw=; b=LzQkpfCsl9JGnm3fcGZHxJRlAtQTrkNozhH3iqeyqP9gS7euOYWQTiKP+e+8rkY5oH hwBcSj2nh9tnoMFcxjPlWb1vgZNctor+KGQ9zqkkB0Zq487VCe0Y759QZyr0U7f1gbnf mv9BXbZrMNRYndzQ0EetXw0d/v8Z1c4GJGerQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=JAAMD5lCjgaZ13CA4PUlo1c5CV7jSf5I58kKGgyO/r/Tj9GYSMFM8PReH+t/YRRnJF yigutNyxgkPWIPmduLx2gsDiEOVG3IDC3zf+gEqd+jH10f+xL1I2N5hiFxjS2oyDuUG/ LH0NlP4b+b0Wv7RheA+TnFlSjrtEM8TPRKAmE= MIME-Version: 1.0 Received: by 10.90.16.34 with SMTP id 34mr1251141agp.47.1254463138089; Thu, 01 Oct 2009 22:58:58 -0700 (PDT) From: Yohanes Nugroho Date: Fri, 2 Oct 2009 12:58:38 +0700 Message-ID: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> To: freebsd-arm@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: FreeBSD ARM network speed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 06:28:27 -0000 Hi All, I am continuing my work on CNX11XX/STR91XX (more info about the work: http://tinyhack.com/2009/09/28/cnx11xxstr91xx-freebsd-progress/), two important things left are the Flash/CFI driver, and network problem. The Flash/CFI in theory should be easy, but I will read more about it to make sure that I will not mess the boot loader part. And now about the network. The network speed is now around half of Linux on the same hardware. FTP-ing from the device to my computer (uploading 30 mb file), the speed is about 1.6-2 megabyte/second (the high speed is on the second time when the data is already cached). On Linux, I can upload the same file with the speed of about 3-4 megabyte/second. Some info about the device: RAM: 64 Mb, CPU FA526 (ARM4, no thumb instruction), Speed 200Mhz. MAC is part of SoC, PHY is ICPLUS IP101A I have two question: 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? If it is slower, then how much slower is it? I can not find a comparison of network speed on Freebsd arm and Linux ARM. I am interested if anyone can provide me the comparison between Linux and Freebsd on NSLU2 or some other device. Just for information, changing some kernel options in the Linux version (such as the scheduler used) makes the network speed varies greatly (i think the variation is more than 30%, so in certain configuration it can be a slow as the current FreeBSD version). The network in Linux 2.4 kernel is faster than Linux 2.6. 2. What should I do to make the network faster (especially the sending from device part, to make it usable as a media server)? Here are the things that I have done: - using the scatter/gather feature of the hardware (this improves the speed a little bit) - using checksum offloading feature of the hardware (this improves the speed a little bit) - using task_queue for sending (this improves the speed a lot) - I have disabled spinlock debugging, and other debugging except for the DDB - I have used the -O2 optimization flag - I have checked that there is no error/retransmission (using wireshark), so all the packets are sent and received correctly - I have disabled IPV6 (here is my current configuration: http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/conf/CNS11XXNAS&REV=3) The specification for the STR9104 SoC is available on Cavium website for those who are interested, but it is not very clear, so in developing the network driver, I followed the logic used by the Linux driver (the initialization sequence, etc). The current code is at http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/econa/if_ece.c&REV=4 Here is how the sending part works on STR9104: - In the initialization part, I allocate a ring, the size of the ring is 256 entries (same as Linux version). - When being asked to send a packet, I will do the following thing: - stop the network TX DMA - put the address of each segment of the packet to the ring, and set a flag so that the entry in the ring will be sent by hardware - start the network TX DMA obviously there is a cleaning up part (freeing mbuf) that should be done. The network driver can generate interrupt when a packet has been sent (but can't tell which entry was sent). In the Linux version, this interrupt is not used, the clean up is done just after starting the TX DMA, at the send of the sending function, and I do the same in the FreeBSD driver . Usually only one entry that needs to be removed, so it is quite fast. Is there something obvious (or not so obvius) that I've missed? -- Regards Yohanes http://yohan.es/ From owner-freebsd-arm@FreeBSD.ORG Fri Oct 2 08:38:15 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 037ED1065672; Fri, 2 Oct 2009 08:38:15 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7F38FC12; Fri, 2 Oct 2009 08:38:14 +0000 (UTC) Received: by fxm22 with SMTP id 22so925883fxm.36 for ; Fri, 02 Oct 2009 01:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=7p2vGu4+SjpeQqeXx1DVsVwbSXyD4KCoQtlrqn81BKg=; b=X1myaGCEJznAttjtxSewrT0jpXsIG53f8Q2x4GtvGs4oXdAgVsyUoI+VvaPYr0+r+5 5henUWpjP9PxEQMQj3Spc/9SOgZVuDzVHlq57UOJb478aVSa0ZYK/D/iKKLb5oRnqkxG JT8+eXX4uqSZ6KSpPMGtnA9WzDzI8hihRTUt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=R6Bhhfq6jovBSxh06m20uV7LEzSPIpW6ZxoArAFesiIDYpHUAZ5qqW1ccnvqNTiTbg JvUoEkYomwZu3JsjVPICswBbkoExWYRlj5tVR1ahKP2dJY+/PRjYen1IIVb68c6KGacw zYId34ZRn8uXQgx2oXxv7RF5nibBe5EVgTwyk= Received: by 10.86.181.6 with SMTP id d6mr2077253fgf.29.1254472693289; Fri, 02 Oct 2009 01:38:13 -0700 (PDT) Received: from mac-mini.lan (bl6-144-180.dsl.telepac.pt [82.155.144.180]) by mx.google.com with ESMTPS id d4sm169824fga.19.2009.10.02.01.38.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Oct 2009 01:38:12 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rui Paulo In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Date: Fri, 2 Oct 2009 09:38:10 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> To: Yohanes Nugroho X-Mailer: Apple Mail (2.1076) Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Subject: Re: FreeBSD ARM network speed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 08:38:15 -0000 On 2 Oct 2009, at 06:58, Yohanes Nugroho wrote: > Hi All, > > I am continuing my work on CNX11XX/STR91XX (more info about the work: > http://tinyhack.com/2009/09/28/cnx11xxstr91xx-freebsd-progress/), two > important things left are the Flash/CFI driver, and network problem. > The Flash/CFI in theory should be easy, but I will read more about it > to make sure that I will not mess the boot loader part. And now about > the network. > > The network speed is now around half of Linux on the same hardware. > FTP-ing from the device to my computer (uploading 30 mb file), the > speed is about 1.6-2 megabyte/second (the high speed is on the second > time when the data is already cached). On Linux, I can upload the same > file with the speed of about 3-4 megabyte/second. > > Some info about the device: RAM: 64 Mb, CPU FA526 (ARM4, no thumb > instruction), Speed 200Mhz. MAC is part of SoC, PHY is ICPLUS IP101A > > I have two question: > 1. Is the network speed in Freebsd ARM currently slower than Linux > ARM? I see no problems on my ARM boards running FreeBSD. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Fri Oct 2 09:35:47 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DF7A106568F; Fri, 2 Oct 2009 09:35:47 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id EFB858FC18; Fri, 2 Oct 2009 09:35:46 +0000 (UTC) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id AD4668FC45; Fri, 2 Oct 2009 13:35:45 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id BC35239C4E; Fri, 2 Oct 2009 13:35:59 +0400 (MSD) Date: Fri, 2 Oct 2009 13:35:59 +0400 From: Stanislav Sedov To: Yohanes Nugroho Message-Id: <20091002133559.283d377f.stas@FreeBSD.org> In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__2_Oct_2009_13_35_59_+0400_1VFBUD8wRLAxVTXc" Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Subject: Re: FreeBSD ARM network speed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 09:35:47 -0000 --Signature=_Fri__2_Oct_2009_13_35_59_+0400_1VFBUD8wRLAxVTXc Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 2 Oct 2009 12:58:38 +0700 Yohanes Nugroho mentioned: > I have two question: > 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? > I don't think so. Our network stack is arch-independent and should perform equally well on all platforms. I've been able to acchieve speeds up to 70 Mbps on my 180Mhz AT91 based board which uses very plain and dumb ethernet controller (although, DMA is supported). > Here is how the sending part works on STR9104: >=20 > - In the initialization part, I allocate a ring, the size of the ring > is 256 entries (same as Linux version). > - When being asked to send a packet, I will do the following thing: > - stop the network TX DMA > - put the address of each segment of the packet to the ring, and set > a flag so that the entry in the ring will be sent by hardware > - start the network TX DMA >=20 This looks weird. Why do you stop the TX engine to add more packets in the ring? This thing definitely can kill the network performace as the controller unable to transmit anything during the time you're filling the ring. You should not also generally transmit only one packet a time as in this case your driver will do a lot of extra work and, considering that you're stopping the TX engine when filling the ring, will prevent the adapter doing any useful work. The main strategy of the driver should be to keep the ring filled, waking up when some reasonable amount of space in the ring become available, and sleeping all other time when the adapter is working. I'm not sure why Linux doesn't use interrupt, but this looks really wrong. I'd suggest you to ananlyze the performance of network driver either by using the profiling tools available (kgmon, hardware counters (if any)) or/and via system monitoring tools (top, etc). Top, in particular, will allow you to see where all the CPU time=20 went. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Fri__2_Oct_2009_13_35_59_+0400_1VFBUD8wRLAxVTXc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKxcl/AAoJEKN82nOYvCd0tLIP/A5SMA8ESLfUMJ+dUtomjNFx Gysrhnsdn9q03R/TeD9wjkyiOGgTdL6NWYPtfV6yH+zJ2nFo0JoPaPT35KRlwzXO 7xXlqQjD5Sp+S4Quc0VHIyDYDDDOxEP3Bp6DkuhTv8J+xHJo1x0pC+yfunpkMygc /rzzWzj4C2hiIgwvn4I9zAPp4AKhzIZNbOAIdL9iHX0v2dnoH1zh15vVB7hTTLsV 8JX1u214Oyi/58E04MDVmMa1mKKnGpzSw3/xo023iCTJt9CTcIyJepsa7LugZaJH BBgurRD7o05uIEY1AaZ/x5KpHAHcBklZ0SY7PSaznDVSuQygRGWNInKnK5vGUmUc 8tQ56GprQNLNsWsN1ABHKhLaPfGZtpFXS4t7e1rD4E26WZ/2qQodzcYjIt8JCbm+ sWIiboYVh7JyEJomUHrkjDw0gfN6i/gEeR0+64V5WLQLt0W8MFZxNwL5EDG61lTY Ikuoi/hIoWLvinAW3rlz6RkXQX3XCxIQGOyBtZvPBOpN+7PoGAq6KKGce4Q/KWJT uM6wO2W0+M1U08Xfu9jdjlN1fIVeTbnic22pFmePzzC8vW1CtQdLIOsHY1f9EiOs pAxgMF8Socd3AZJm4nK+zcrnwH2zzbomTV3we7AfLqUombm9axl4B1YmV+1ICXvF rHMHjekU6zvV7O/P7VrF =TnRO -----END PGP SIGNATURE----- --Signature=_Fri__2_Oct_2009_13_35_59_+0400_1VFBUD8wRLAxVTXc-- From owner-freebsd-arm@FreeBSD.ORG Fri Oct 2 11:56:08 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83A99106566B; Fri, 2 Oct 2009 11:56:08 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 986858FC13; Fri, 2 Oct 2009 11:56:07 +0000 (UTC) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 542D78FC45; Fri, 2 Oct 2009 15:56:05 +0400 (MSD) Date: Fri, 2 Oct 2009 15:56:00 +0400 From: Stanislav Sedov To: Tom Judge Message-Id: <20091002155600.2c2f615d.stas@FreeBSD.org> In-Reply-To: <4AC599FC.1070304@tomjudge.com> References: <4AC599FC.1070304@tomjudge.com> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__2_Oct_2009_15_56_00_+0400_PhnE7R=+KxvjIANj" Cc: freebsd-arm@freebsd.org, cognet@FreeBSD.org Subject: Re: [patch] Compilation problems in sys/arm/arm/pmap.c when PMAP_DEBUG is defined. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 11:56:08 -0000 --Signature=_Fri__2_Oct_2009_15_56_00_+0400_PhnE7R=+KxvjIANj Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 02 Oct 2009 06:13:16 +0000 Tom Judge mentioned: > Hi, >=20 > I ran into some issues this evening while I was building some kernels=20 > with PMAP_DEBUG defined. >=20 > I have attached a patch that addresses the problems with the DPRINTF=20 > sections. (The first 2 hunks should probably be ignored). >=20 > However there are 2 warnings about unused functions when PMAP_INLINE is=20 > defined as "". I did not know what the correct fix for this was so I=20 > defined PMAP_INLINE to __inline even when PMAP_DEBUG was set, which=20 > seemed to hide the problem again. >=20 Actually, these two functions with PMAP_INLINE prefixes are unused. I believe we can drop them. Olivier, what do you think about the following patch? Index: sys/arm/arm/pmap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/arm/arm/pmap.c (revision 197707) +++ sys/arm/arm/pmap.c (working copy) @@ -203,7 +203,6 @@ static void pmap_fix_cache(struct vm_page *, pmap_t, vm_offset_t); static void pmap_alloc_l1(pmap_t); static void pmap_free_l1(pmap_t); -static void pmap_use_l1(pmap_t); =20 static int pmap_clearbit(struct vm_page *, u_int); =20 @@ -829,47 +828,6 @@ mtx_unlock(&l1_lru_lock); } =20 -static PMAP_INLINE void -pmap_use_l1(pmap_t pm) -{ - struct l1_ttable *l1; - - /* - * Do nothing if we're in interrupt context. - * Access to an L1 by the kernel pmap must not affect - * the LRU list. - */ - if (pm =3D=3D pmap_kernel()) - return; - - l1 =3D pm->pm_l1; - - /* - * If the L1 is not currently on the LRU list, just return - */ - if (l1->l1_domain_use_count =3D=3D PMAP_DOMAINS) - return; - - mtx_lock(&l1_lru_lock); - - /* - * Check the use count again, now that we've acquired the lock - */ - if (l1->l1_domain_use_count =3D=3D PMAP_DOMAINS) { - mtx_unlock(&l1_lru_lock); - return; - } - - /* - * Move the L1 to the back of the LRU list - */ - TAILQ_REMOVE(&l1_lru_list, l1, l1_lru); - TAILQ_INSERT_TAIL(&l1_lru_list, l1, l1_lru); - - mtx_unlock(&l1_lru_lock); -} - - /* * Returns a pointer to the L2 bucket associated with the specified pmap * and VA, or NULL if no L2 bucket exists for the address. @@ -1311,16 +1269,6 @@ } } =20 -static PMAP_INLINE void -pmap_dcache_wbinv_all(pmap_t pm) -{ - - if (pmap_is_current(pm)) { - cpu_dcache_wbinv_all(); - cpu_l2cache_wbinv_all(); - } -} - /* * PTE_SYNC_CURRENT: * @@ -1914,7 +1862,7 @@ { int shpgperproc =3D PMAP_SHPGPERPROC; =20 - PDEBUG(1, printf("pmap_init: phys_start =3D %08x\n")); + PDEBUG(1, printf("pmap_init: phys_start =3D %08x\n", PHYSADDR)); =20 /* * init the pv free list @@ -2373,8 +2321,8 @@ vm_size_t size; int l1idx, l2idx, l2next =3D 0; =20 - PDEBUG(1, printf("firstaddr =3D %08x, loadaddr =3D %08x\n", - firstaddr, loadaddr)); + PDEBUG(1, printf("firstaddr =3D %08x, lastaddr =3D %08x\n", + firstaddr, lastaddr)); =09 virtual_avail =3D firstaddr; kernel_pmap->pm_l1 =3D l1; @@ -4246,96 +4194,7 @@ pmap_zero_page(m); } =20 -#if 0 /* - * pmap_clean_page() - * - * This is a local function used to work out the best strategy to clean - * a single page referenced by its entry in the PV table. It's used by - * pmap_copy_page, pmap_zero page and maybe some others later on. - * - * Its policy is effectively: - * o If there are no mappings, we don't bother doing anything with the ca= che. - * o If there is one mapping, we clean just that page. - * o If there are multiple mappings, we clean the entire cache. - * - * So that some functions can be further optimised, it returns 0 if it did= n't - * clean the entire cache, or 1 if it did. - * - * XXX One bug in this routine is that if the pv_entry has a single page - * mapped at 0x00000000 a whole cache clean will be performed rather than - * just the 1 page. Since this should not occur in everyday use and if it = does - * it will just result in not the most efficient clean for the page. - */ -static int -pmap_clean_page(struct pv_entry *pv, boolean_t is_src) -{ - pmap_t pm, pm_to_clean =3D NULL; - struct pv_entry *npv; - u_int cache_needs_cleaning =3D 0; - u_int flags =3D 0; - vm_offset_t page_to_clean =3D 0; - - if (pv =3D=3D NULL) { - /* nothing mapped in so nothing to flush */ - return (0); - } - - /* - * Since we flush the cache each time we change to a different - * user vmspace, we only need to flush the page if it is in the - * current pmap. - */ - if (curthread) - pm =3D vmspace_pmap(curproc->p_vmspace); - else - pm =3D pmap_kernel(); - - for (npv =3D pv; npv; npv =3D TAILQ_NEXT(npv, pv_list)) { - if (npv->pv_pmap =3D=3D pmap_kernel() || npv->pv_pmap =3D=3D pm) { - flags |=3D npv->pv_flags; - /* - * The page is mapped non-cacheable in=20 - * this map. No need to flush the cache. - */ - if (npv->pv_flags & PVF_NC) { -#ifdef DIAGNOSTIC - if (cache_needs_cleaning) - panic("pmap_clean_page: " - "cache inconsistency"); -#endif - break; - } else if (is_src && (npv->pv_flags & PVF_WRITE) =3D=3D 0) - continue; - if (cache_needs_cleaning) { - page_to_clean =3D 0; - break; - } else { - page_to_clean =3D npv->pv_va; - pm_to_clean =3D npv->pv_pmap; - } - cache_needs_cleaning =3D 1; - } - } - if (page_to_clean) { - if (PV_BEEN_EXECD(flags)) - pmap_idcache_wbinv_range(pm_to_clean, page_to_clean, - PAGE_SIZE); - else - pmap_dcache_wb_range(pm_to_clean, page_to_clean, - PAGE_SIZE, !is_src, (flags & PVF_WRITE) =3D=3D 0); - } else if (cache_needs_cleaning) { - if (PV_BEEN_EXECD(flags)) - pmap_idcache_wbinv_all(pm); - else - pmap_dcache_wbinv_all(pm); - return (1); - } - return (0); -} -#endif - -/* * pmap_copy_page copies the specified (machine independent) * page by mapping the page into virtual memory and using * bcopy to copy the page, one machine dependent page at a --=20 Stanislav Sedov ST4096-RIPE --Signature=_Fri__2_Oct_2009_15_56_00_+0400_PhnE7R=+KxvjIANj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKxepVAAoJEKN82nOYvCd0cQoP/RVV0j3Hj6Jt1giEfanEcfCK PL+xtfXQhbyuwTH+fVAJcCdQN1iK1OzufWj5pLg62EM0ckLUsKmPRdvdEQGCoJUZ 3xYeSinPRtPrk53mzKEQ/OUbyJIOutmHmjlI/2feSHudZvS+8GTRDDeA8b7Tiwq3 mDaU1jCgcioh22ou1BvRMT65ejAASISA6Q8s5VSwCHXSbrYw9gP6QeuSZv8Nxxbq 5XVZJOOgl1+KkM0Im6Q7sq33ssYOAZCBLgH9UFlYFSY1U1dIaGedCP7/zQ8hcViJ QT6Elq3d0f7rSE22zHThsAr1cEcMPOyrxyLzM1xyfawJY1OjiZWTJJHu1mGc0NHw hcGxrh+I0POC1tUBobgXGePHcvFI0L6zB44RwgP+4STOSvsQjbxYUWzpB992qe9y 8UiUpfPPKAoyg2e4Z4KGjxAnRtIw+5RcsAYBUSzBlOpIezZ4Devt2oCjZUf6btfd SbbFGj9wf5m+FRv9hF8vdrQSzzSQw0s3II4Xs8gVNW1YwrrRXBVQq2EtKqs7/JqE +NJhBxSP5fXD5gFSzI1JRTyMBH1Gp0j3d2OdeSh/U2CqzrvuULXaVGDm0fzKphoe 8k+RAybILbump+hAOTmZKsB+mm71tnrF5JnTLOCUhFv2GtjifIX9MXmvdp9iOKqV udjWI1C5T6/6IdpBt7ZZ =iM/H -----END PGP SIGNATURE----- --Signature=_Fri__2_Oct_2009_15_56_00_+0400_PhnE7R=+KxvjIANj-- From owner-freebsd-arm@FreeBSD.ORG Fri Oct 2 12:24:59 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 000411065670; Fri, 2 Oct 2009 12:24:58 +0000 (UTC) (envelope-from yohanes@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id BCD358FC15; Fri, 2 Oct 2009 12:24:58 +0000 (UTC) Received: by pzk15 with SMTP id 15so323433pzk.3 for ; Fri, 02 Oct 2009 05:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=DGpems6qWEVK0M/oILdZG1niZ7vCQ/dxLINbXzrFDNc=; b=Leld7TWZPVWg2ySzaGblDMzFMIYHyQfp/zPQxGuatdbZIMIpYaUn5IrW1GZKQZhUuS 9X3RrTexE3ziPUYeDoSXgG4BggHu/GFYrrontFDebyxjghBgo39ZF9es4OfV89S9mzJ/ qORwqPjxBO3uqyOH81fOziAj4kNeDt56J0OyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=iZOVGDkYpfB1TvxGzMRI/H++CyHIt0XlLBBz5OntrBUMYcgJKhzSkHvEXM0VA2tcAP EdI8LCIlImZgPI3OQ8Tb+Grq+1FS4bxfSiC4wr8cr2222ijoqu0nFMsJzFLdkvMAuMsk EdKYkauuK/qL7uZR7YMY8rJ4EI0OMrZHatkgA= MIME-Version: 1.0 Received: by 10.142.61.41 with SMTP id j41mr322357wfa.335.1254486298370; Fri, 02 Oct 2009 05:24:58 -0700 (PDT) In-Reply-To: <20091002133559.283d377f.stas@FreeBSD.org> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> <20091002133559.283d377f.stas@FreeBSD.org> From: Yohanes Nugroho Date: Fri, 2 Oct 2009 19:24:38 +0700 Message-ID: <260bb65e0910020524p374a7706r21c72a12b8ce93fb@mail.gmail.com> To: Stanislav Sedov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Subject: Re: FreeBSD ARM network speed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 12:24:59 -0000 On Fri, Oct 2, 2009 at 4:35 PM, Stanislav Sedov wrote: > On Fri, 2 Oct 2009 12:58:38 +0700 > Yohanes Nugroho mentioned: > >> I have two question: >> 1. Is the network speed in Freebsd ARM currently slower than Linux ARM? >> > > I don't think so. =C2=A0Our network stack is arch-independent and should = perform > equally well on all platforms. =C2=A0I've been able to acchieve speeds up= to > 70 Mbps on my 180Mhz AT91 based board which uses very plain and dumb > ethernet controller (although, DMA is supported). Ok, glad to hear that :) because the first time I asked about a problem in the USB, it turns out that there was a problem in the latest source code in busdma, and I have spent several days thinking it was my bug. > > This looks weird. =C2=A0Why do you stop the TX engine to add more packets > in the ring? =C2=A0This thing definitely can kill the network performace yes, you are right, that is weird, I will have a look at it again. > The main strategy of the driver should be to keep the ring filled, > waking up when some reasonable amount of space in the ring become > available, and sleeping all other time when the adapter is working. Thank you for your enlightenment. > I'm not sure why Linux doesn't use interrupt, but this looks really > wrong. It is because the driver comes from a vendor (very messy code), not in the mainline kernel yet. the background story: - I have a cheap chinese NAS device (Agestar NCB3AST, cost about $50, now you can get it for about $40), comes with linux kernel 2.4, no source code was given. SoC used is Starsemi 9104 - I found out that there is a Linux source code for this SoC but for different device (with different hardware around the SoC). - Based on the source code, I ported it to work on Linux kernel 2.6, I didn't bother to try to clean up the source code - I am thinking of trying to add my code to mainline kernel, I realized that I didn't understand most of the source code - Bruce Simpson offered a device with same SoC (NSD-100) and I tried to port FreeBSD to it, thinking that I will understand the SoC better when rewriting the code - Starsemi was bought by cavium, the SoC is renamed to Econa CNS1102, and the datasheet was released. The datasheet is not very clear, so I am still basing some of my code on the Linux code (just the logic, not copy pasting, I understand about the license implication). > I'd suggest you to ananlyze the performance of network driver > either by using the profiling tools available (kgmon, hardware > counters (if any)) or/and via system monitoring tools (top, etc). > Top, in particular, will allow you to see where all the CPU time > went. I am testing in single user mode. Last time i tested using kgmon, it doesn't show any particular area that might cause the slowdown. Once again, thank you, I now have some ideas on what to do this weekend. --=20 Regards Yohanes http://yohan.es/ From owner-freebsd-arm@FreeBSD.ORG Fri Oct 2 20:47:28 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA489106566B for ; Fri, 2 Oct 2009 20:47:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 691678FC1C for ; Fri, 2 Oct 2009 20:47:28 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so7052fga.13 for ; Fri, 02 Oct 2009 13:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=VDuflTs1fx/NomRv1jqTV2kQ9IKtA55l5OIyZzToSwk=; b=jXXR0eYmQlsolvDeB6fiCqsI7r1Xi7ipsC6KMihZHQ2t78zyJhi8C1k500/820XH7L gg5ffqIlXzeugUgNRW3h1cRmTKNy20bGAZ1R9Xm94Ws7CGh7EJv8dZsRMbdWaI4STMLH ZvNkcWRmn1o35kcAiUFlLyMMEyoox8tRqEZ70= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=twdBdbW0iY7BPV8a3Dwo3plK0WKoyZK1aEYK4SLDszUKOjILy6k0vU65kmg62dd9of +VOnCB7kxXJ2Y3SHRnev9p2pwlKGf2gF/85MLrzaS+JHKqKH1+oQii97a6SjhjsM7Pjl cCZoahrZdyNmFJUmsTUC0ROIGLHR/ERhb5fWw= Received: by 10.86.238.30 with SMTP id l30mr2664596fgh.75.1254514485603; Fri, 02 Oct 2009 13:14:45 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id l19sm16049fgb.16.2009.10.02.13.14.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Oct 2009 13:14:44 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 2 Oct 2009 13:14:00 -0700 From: Pyun YongHyeon Date: Fri, 2 Oct 2009 13:14:00 -0700 To: Yohanes Nugroho Message-ID: <20091002201400.GJ1512@michelle.cdnetworks.com> References: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-arm@freebsd.org Subject: Re: FreeBSD ARM network speed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 20:47:29 -0000 On Fri, Oct 02, 2009 at 12:58:38PM +0700, Yohanes Nugroho wrote: > Hi All, > Hi, [...] > The specification for the STR9104 SoC is available on Cavium website > for those who are interested, but it is not very clear, so in > developing the network driver, I followed the logic used by the Linux > driver (the initialization sequence, etc). The current code is at > http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/str91xx/src/sys/arm/econa/if_ece.c&REV=4 > > Here is how the sending part works on STR9104: > > - In the initialization part, I allocate a ring, the size of the ring > is 256 entries (same as Linux version). If ethernet controller does not support 1000baseT(I think it's fastethernt because ICPlus IP101A is 10/100 PHY) allocating 256 descriptors are waste of resource especially on 64MB systems, I think. > - When being asked to send a packet, I will do the following thing: > - stop the network TX DMA > - put the address of each segment of the packet to the ring, and set > a flag so that the entry in the ring will be sent by hardware > - start the network TX DMA > > obviously there is a cleaning up part (freeing mbuf) that should be > done. The network driver can generate interrupt when a packet has been > sent (but can't tell which entry was sent). In the Linux version, this > interrupt is not used, the clean up is done just after starting the TX > DMA, at the send of the sending function, and I do the same in the > FreeBSD driver . Usually only one entry that needs to be removed, so > it is quite fast. > > Is there something obvious (or not so obvius) that I've missed? > I briefly looked over the driver code and I can see missing bus_dmamap_sync(9) in several places as well as incorrect use of bus_dma(9). This may also affect performance because checking OWN bit wouldn't be correct in CPU's view without bus_dmamap_sync(9). Another poor performance might come from m_devget(9), I don't know whether controller really needs this type of copying(sorry, have no time to read data sheet) but m_devget(9) is really slow and time consuming operation because it has to copy entire frame to new mbuf. If you had to use m_devget(9) to align buffers on ETHER_ALIGN boundary I guess you can pass the alignment restriction to bus_dma(9). Of course, this requires the controller have ability to receive frames on even address boundary or no Rx buffer alignment limitation. I believe you should not stop DMA before sending another frame as you did in Rx handler. Basically you should make controller as busy as you can to get maximum performance and should reclaim transmitted buffers as soon as you noticed. Stopping DMA may take time since it may have to drain active DMA cycles. If the controller does not generate Tx completion interrupt after sending a frame, which is not likely, you may have to implement a kind of polling in separate thread or should use polling(9). Good luck!