From: itooo@itooo.com (Greg)
To: linux-arm-kernel@lists.infradead.org
Subject: MVEBU and MVNETA driver
Date: Mon, 22 Apr 2013 10:19:41 +0200 [thread overview]
Message-ID: <5174F29D.5070908@itooo.com> (raw)
In-Reply-To: <20130422062024.GK30850@1wt.eu>
Le 22/04/2013 08:20, Willy Tarreau a ?crit :
> On Fri, Apr 19, 2013 at 06:02:19PM +0200, Greg wrote:
>> A simple tool like netcat shows ~470Mbps but this limited by the CPU.
>> Iperf isn't CPU limited
>>
>> The same test with Marvell LSP shows ~940Mbps in both directions.
> I've retested here on my mirabox using httpterm as the tcp server.
> Using the normal send() syscall, it emits 839 Mbps on a single TCP
> connection. Using splice(), it emits 969 Mbps in the same conditions.
>
> Here's what ethtool is saying about the NIC's tuning :
> # ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: off
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: off
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off
> rx-vlan-offload: off
> tx-vlan-offload: off
> ntuple-filters: off
> receive-hashing: off
>
> I've tried changing other settings such as the interrupt delays
> (rx-usecs, rx-frames, tx-frames) but this has no effect. So in
> short, I cannot reproduce this behaviour. Are you using the SLOB
> allocator ? I'm asking because I remember experiencing very poor
> performance with it in the past.
>
Willy,
I'm using SLAB allocator.
As for offloading, I can't seem to be able to turn it on :
> $ ethtool -K eth0 gro on
> Cannot set device GRO settings: Operation not supported
> $ ethtool -K eth0 gso on
> Cannot set device generic segmentation offload settings: Operation not
> supported
Default values :
> $ ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: off
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: off
> udp-fragmentation-offload: off
> generic-segmentation-offload: off
> generic-receive-offload: off
> large-receive-offload: off
> rx-vlan-offload: off
> tx-vlan-offload: off
> ntuple-filters: off
> receive-hashing: off
I can see 1 difference between our setups, Mirabox has an Armada370, I
have an ArmadaXP, it would be interesting to know what Gregory is using.
Another difference on my setup, and something I wanted to report you :
there is no PHY on my system. I had to instantiate a dummy PHY in the
device tree blob and bind it to the mvneta driver because it would fail
at init without PHY.
Regards,
next prev parent reply other threads:[~2013-04-22 8:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-19 13:07 MVEBU and MVNETA driver Greg
2013-04-19 13:12 ` Willy Tarreau
2013-04-19 14:13 ` Greg
2013-04-19 14:43 ` Willy Tarreau
2013-04-19 14:59 ` Gregory CLEMENT
2013-04-19 16:02 ` Greg
2013-04-22 6:20 ` Willy Tarreau
2013-04-22 8:19 ` Greg [this message]
2013-04-22 9:08 ` Willy Tarreau
2013-04-22 9:40 ` Greg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5174F29D.5070908@itooo.com \
--to=itooo@itooo.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).