netdev - RE: [PATCH] x86/lib: Remove the special case for odd-aligned buffers in csum

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:   Mon, 13 Dec 2021 15:37:15 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Dave Hansen' <dave.hansen@...el.com>,
        'Noah Goldstein' <goldstein.w.n@...il.com>,
        Eric Dumazet <edumazet@...gle.com>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        X86 ML <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "alexanderduyck@...com" <alexanderduyck@...com>,
        open list <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: RE: [PATCH] x86/lib: Remove the special case for odd-aligned buffers
 in csum_partial.c

From: Dave Hansen
> Sent: 13 December 2021 15:02
.c
> 
> On 12/13/21 6:43 AM, David Laight wrote:
> > There is no need to special case the very unusual odd-aligned buffers.
> > They are no worse than 4n+2 aligned buffers.
> >
> > Signed-off-by: David Laight <david.laight@...lab.com>
> > ---
> >
> > On an i7-7700 misaligned buffers add 2 or 3 clocks (in 115) to a 512 byte
> >   checksum.
> > That is just measuring the main loop with an lfence prior to rdpmc to
> > read PERF_COUNT_HW_CPU_CYCLES.
> 
> I'm a bit confused by this changelog.
> 
> Are you saying that the patch causes a (small) performance regression?
> 
> Are you also saying that the optimization here is not worth it because
> it saves 15 lines of code?  Or that the misalignment checks themselves
> add 2 or 3 cycles, and this is an *optimization*?

I'm saying that it can't be worth optimising for a misaligned
buffer because the cost of the buffer being misaligned is so small.
So the test for a misaligned buffer are going to cost more than
and plausible gain.

Not only that the buffer will never be odd aligned at all.

The code is left in from a previous version that did do aligned
word reads - so had to do extra for odd alignment.

Note that code is doing misaligned reads for the more likely 4n+2
aligned ethernet receive buffers.
I doubt that even a test for that would be worthwhile even if you
were checksumming full sized ethernet packets.

So the change is deleting code that is never actually executed
from the hot path.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)