[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iKbc=btFW9mJazEmNY==rqqtHo8AD5_asCQN6kMRUd11g@mail.gmail.com>
Date: Fri, 12 Nov 2021 09:42:23 -0800
From: Eric Dumazet <edumazet@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
netdev <netdev@...r.kernel.org>, x86@...nel.org,
Alexander Duyck <alexander.duyck@...il.com>,
Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: [PATCH v2] x86/csum: rewrite csum_partial()
On Fri, Nov 12, 2021 at 9:36 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Fri, Nov 12, 2021 at 9:23 AM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > On Fri, Nov 12, 2021 at 8:45 AM Peter Zijlstra <peterz@...radead.org> wrote:
> > >
> >
> > >
> > > Looks nice, happen to have shiny perf numbers to show how awesome it it?
> > > :-)
> >
> > On a networking load on cascadlake, line rate received on a single thread, I see
> > perf -e cycles:pp -C <cpu>
> >
> > Before:
> > 4.16% [kernel] [k] csum_partial
> > After:
> > 0.83% [kernel] [k] csum_partial
> >
> > If run in a loop 1,000,000 times,
> >
>
> However, there must be an error in my patch, return values are not the
> same on unaligned buffers.
Oh silly me, the 32bit value is different, but the 16bit csum is good,
sorry for the noise.
Powered by blists - more mailing lists