netdev - RE: [PATCH 3/7] mlx4_en: Incoming traffic alignment optimizations

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] [day] [month] [year] [list]

Message-ID: <953B660C027164448AE903364AC447D2235EEC59@MTLDAG01.mtl.com>
Date:	Tue, 18 Oct 2011 08:52:03 +0000
From:	Yevgeny Petrilin <yevgenyp@...lanox.co.il>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH 3/7] mlx4_en: Incoming traffic alignment optimizations

> 
> Oh my...
> 
> Of course you are aware that the 'truesize' stuff around means that using big frag size will probably lower your performance number, unless you allow protocol stacks to use more ram ?
> 
> Only possible drawback using 512 bytes instead of 2048 is the cache-line bounce on the page->_count field. So I would say your change hides a performance issue of your driver.
> 
> Maybe you should make sure you dont touch it too often [ You should use a single add per allocated PAGE, not 2 (for 2048-bytes frags) or 8 (for 512-bytes frags) ]
> 
> 
Thanks Eric,
I'll check this.
In the meanwhile will resubmit the series without this change.