lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BE3E6F5.5050601@monstr.eu>
Date:	Fri, 07 May 2010 12:09:57 +0200
From:	Michal Simek <monstr@...str.eu>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	hadi@...erus.ca, therbert@...gle.com,
	microblaze-uclinux@...e.uq.edu.au
Subject: Re: [PATCH net-next-2.6] net: Increase NET_SKB_PAD to 64 bytes

Eric Dumazet wrote:
> Le vendredi 07 mai 2010 à 11:48 +0200, Michal Simek a écrit :
>> David Miller wrote:
>>> From: Michal Simek <monstr@...str.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ