From: Michal Simek <monstr@monstr.eu>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, hadi@cyberus.ca, therbert@google.com,
microblaze-uclinux@itee.uq.edu.au
Subject: Re: [PATCH net-next-2.6] net: Increase NET_SKB_PAD to 64 bytes
Date: Fri, 07 May 2010 12:09:57 +0200 [thread overview]
Message-ID: <4BE3E6F5.5050601@monstr.eu> (raw)
In-Reply-To: <1273226114.2261.42.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le vendredi 07 mai 2010 à 11:48 +0200, Michal Simek a écrit :
>> David Miller wrote:
>>> From: Michal Simek <monstr@monstr.eu>
>>> Date: Fri, 07 May 2010 09:53:48 +0200
>>>
>>>> I will add this Microblaze patch to my repo for testing and anyway
>>>> should go through my repo.
>>> It's already in the net-next-2.6 tree.
>> Anyway.
>>
>> I am ok with removing NET_IP_ALIGN because it is already defined in
>> skbuff.h to 2.
>> But increasing NET_SKB_PAD to 64 caused that Microblaze extends skb
>> buffers for some bytes.
>> I measured it by iperf and netperf and I see regression around 1-2Mbit/s
>> that's why I would like to ask you to revert this patch or keep at least
>> NET_SKB_PAD part.
>
> Interesting.
>
> Increasing NET_SKB_PAD to say 128 or 256 should not have performance
> impact, but reserve a bit more ram. (truesize...)
yes. Microblaze is very sensitive on it. I have spent a couple of days
to find out why bandwidth is so bad and I found that truesize is the
problem. Whole driver allocated skb buffer to max mtu size (9000).
But if mtu is 1500 the driver still worked with max skb buffers size
Please correct me if I am wrong but if truesize is setup to 9000 then
net code is working with that size even if mtu is 1500.
The next thing is that cache operations take a lot of cpu cycles.
I create a patch which allocated aligned skb buffers where size depends
on current mtu size and this change rapidly increase bandwidth for
mtu=1500 from 8Mb/s to 35Mb/s (depends on setting). There is no
difference if jumbo frames are used (I means for driver with/without my
patch).
>
> Investigation is needed. Maybe your NIC now allocates high order pages ?
>
> What driver are you using ?
>
I am using non-mainline ll_temac driver.
drivers/net/xilinx_lltemac/
http://developer.petalogix.com/git/gitweb.cgi?p=linux-2.6-microblaze.git;a=shortlog
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
next prev parent reply other threads:[~2010-05-07 10:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 5:24 [PATCH net-next-2.6] net: Increase NET_SKB_PAD to 64 bytes Eric Dumazet
2010-05-07 5:02 ` David Miller
2010-05-07 5:15 ` Eric Dumazet
2010-05-07 5:28 ` [microblaze-uclinux] " John Williams
2010-05-07 6:29 ` David Miller
2010-05-07 7:53 ` Michal Simek
2010-05-07 8:32 ` David Miller
2010-05-07 9:02 ` Michal Simek
2010-05-07 9:48 ` Michal Simek
2010-05-07 9:55 ` Eric Dumazet
2010-05-07 10:09 ` Michal Simek [this message]
2010-05-07 10:27 ` Eric Dumazet
2010-05-07 9:56 ` David Miller
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=4BE3E6F5.5050601@monstr.eu \
--to=monstr@monstr.eu \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=hadi@cyberus.ca \
--cc=microblaze-uclinux@itee.uq.edu.au \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.com \
/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).