netdev - Re: [PATCH net-next-2.6] net: Increase NET_SKB

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]

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