[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fce08e76da7e3882319ae935c38e9e2eccf2dcae.camel@redhat.com>
Date: Wed, 26 Jul 2023 15:44:29 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: David Laight <David.Laight@...LAB.COM>,
"'willemdebruijn.kernel@...il.com'" <willemdebruijn.kernel@...il.com>,
"'davem@...emloft.net'" <davem@...emloft.net>, "'dsahern@...nel.org'"
<dsahern@...nel.org>, 'Eric Dumazet' <edumazet@...gle.com>,
"'kuba@...nel.org'" <kuba@...nel.org>, "'netdev@...r.kernel.org'"
<netdev@...r.kernel.org>
Subject: Re: [PATCH 1/2] Move hash calculation inside udp4_lib_lookup2()
On Wed, 2023-07-26 at 12:05 +0000, David Laight wrote:
> Pass the udptable address into udp4_lib_lookup2() instead of the hash slot.
>
> While ipv4_portaddr_hash(net, IP_ADDR_ANY, 0) is constant for each net
> (the port is an xor) the value isn't saved.
> Since the hash function doesn't get simplified when passed zero the hash
Are you sure? could you please objdump and compare the binary code
generated before and after the patch? In theory all the callers up to
__jhash_final() included should be inlined, and the compiler should be
able to optimze at least rol32(0, <n>).
Cheers,
Paolo
Powered by blists - more mailing lists