public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: itooo@itooo•com (Greg)
To: linux-arm-kernel@lists•infradead.org
Subject: MVEBU and MVNETA driver
Date: Mon, 22 Apr 2013 11:40:57 +0200	[thread overview]
Message-ID: <517505A9.20600@itooo.com> (raw)
In-Reply-To: <20130422090803.GA3715@1wt.eu>

Le 22/04/2013 11:08, Willy Tarreau a ?crit :
> On Mon, Apr 22, 2013 at 10:19:41AM +0200, Greg wrote:
>> 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.
> OK so I guess you have a kernel version prior to 3.9-rc7. There is a bug
> in the driver which causes it to report tx cksum and sg but they're not
> enabled. You need to disable then enable them :
>
>    ethtool -K eth0 tx off
>    ethtool -K eth0 sg off
>    ethtool -K eth0 tx on
>    ethtool -K eth0 sg on
>
> Then you can enable gso/gro. And that clearly explains a significant
> performance difference.
Yes, as explain in my original mail, I'm using 3.8.8
I followed your recommendations and performance is now ~930-940Mbits in 
both directions which is fine.
Thanks !
>> 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.
> I think this is more something for Thomas then.
>
The "failure" is located in mvneta_mdio_probe but I guess this is more 
like an architectural problem.
The MVNETA driver assumes a PHY is present, but this is not a 
requirement to establish link between 2 MACs.
I guess using a dummy PHY is a not-so-bad idea for my situation at this 
time.

Regards,

      reply	other threads:[~2013-04-22  9:40 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
2013-04-22  9:08               ` Willy Tarreau
2013-04-22  9:40                 ` Greg [this message]

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=517505A9.20600@itooo.com \
    --to=itooo@itooo$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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