netdev - [PATCH 0/25] Kill stack space gaps due to flowi layout.

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

Message-Id: <20110312.152351.189687538.davem@davemloft.net>
Date:	Sat, 12 Mar 2011 15:23:51 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	netdev@...r.kernel.org
Subject: [PATCH 0/25] Kill stack space gaps due to flowi layout.

One thing we got wrong from the beginning was the layout of
struct flowi.  It's suboptimal by design.

For ipv4, for example, huge gaps exist between the addressing
information and the "ports".  This is because we put the
addressing information for all AF types side-by-side in a
union so there is a gap because the ipv6 addresses take up
more space.

There were also completely unused portions of struct flowi due
to padding.

So as a result we get less dense data accesses, and therefore
less successful store buffer compression and less cache locality.

Lucky for us, all code paths that touch the AF dependent portions
do so in an AF dependent context.  Therefore we can lay things out
any way we like.

So these changes pack things together as tightly as possible for
each AF variant.  And AF independent code is only allowed to
make references to the "common" area at the beginning of each
AF instance.

Performance improvement is measurable, even a routing cache hit
output route lookup is ~20 cycles faster on Niagara2.  udpflood
tests are also faster by several seconds.

I tried to minimize the noise and churn by making ipv4 helpers
for various common cases of route lookups.  But some code paths
want to do something very special (f.e. icmp) and I did not work
on such helpers for ipv6.  That can be done at a later time.

And in fact, ipv6 is really an area ripe for consolidation of routing
lookups.  The same flowlabel resolution sequence probably occurs 10
times in the tree.

And hey, even decnet got some love here.

What I'll do tonight is push this to net-next-2.6 and then respin
the routing cache deletion patches, since those obviously won't
apply any longer. :)
--
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