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

Message-ID: <1318927207.2657.10.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Date:	Tue, 18 Oct 2011 10:40:07 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Yevgeny Petrilin <yevgenyp@...lanox.co.il>
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

Le mardi 18 octobre 2011 à 07:43 +0000, Yevgeny Petrilin a écrit :
> > 
> > > @@ -91,7 +91,7 @@
> > >  /* Receive fragment sizes; we use at most 4 fragments (for 9600 byte MTU
> > >   * and 4K allocations) */
> > >  enum {
> > > -	FRAG_SZ0 = 512 - NET_IP_ALIGN,
> > > +	FRAG_SZ0 = 2048,
> > >  	FRAG_SZ1 = 1024,
> > >  	FRAG_SZ2 = 4096,
> > >  	FRAG_SZ3 = MLX4_EN_ALLOC_SIZE
> > 
> > Is the 512 -> 2048 change really wanted ? Its not mentioned in changelog and is confusing.
> > 
> > This means mlx4 lost the ability to use a small frag (512 bytes) to store small frames.
> > 
> The change is wanted as an optimization for our HW.
> We do get better numbers with this change, even with small packets.
> You are correct, I should have mentioned it in the changelog.

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) ]



--
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