Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 Oct 2009 12:58:38 +0700
From:      Yohanes Nugroho <yohanes@gmail.com>
To:        freebsd-arm@freebsd.org, freebsd-net@freebsd.org
Subject:   FreeBSD ARM network speed
Message-ID:  <260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
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/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?260bb65e0910012258w7c569505xa8cac5bd8bbd2aaa>