All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Eric Dumazet' <eric.dumazet@gmail.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Cc: netdev <netdev@vger.kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	"x86@kernel.org" <x86@kernel.org>,
	Alexander Duyck <alexander.duyck@gmail.com>
Subject: RE: [RFC] x86/csum: rewrite csum_partial()
Date: Mon, 15 Nov 2021 10:23:31 +0000	[thread overview]
Message-ID: <e08af965e5b4422e9b38d8ccd90f8e7b@AcuMS.aculab.com> (raw)
In-Reply-To: <3f7414264ba0456b9102dd63c695272e@AcuMS.aculab.com>

From: David Laight
> Sent: 14 November 2021 14:12
> ..
> > If you aren't worried (too much) about cpu before Broadwell then IIRC
> > this loop gets close to 8 bytes/clock:
> >
> > +               "10:    jecxz 20f\n"
> > +               "       adc   (%[buff], %[len]), %[sum]\n"
> > +               "       adc   8(%[buff], %[len]), %[sum]\n"
> > +               "       lea   16(%[len]), %[tmp]\n"
> > +               "       jmp   10b\n"
> > +               " 20:"
> 
> It is even possible a loop based on:
> 	10:	adc	(%[buff], %[len], 8), %sum
> 		inc	%[len]
> 		jnz	10b
> will run at 8 bytes per clock on very recent Intel cpu.

It doesn't on i7-7700.
(which I probably tested last year).

But the first loop does run twice as fast - and will only
be beaten by the adcx/adox loop.
So there is no need to unroll to more than 2 reads/loop.

For cpu between Ivy bridge and Broadwell you want to use
separate 'sum' registers to avoid the 2 clock latency
of the adc result.
That should beat the 4 bytes/clock of the current loop.
But does need an extra unroll to get near 8 bytes/clock.

For older cpu (nehalem/core2) the 'jecxz' loop is about the
only way to 'loop carry' the carry flag without the
6 clock penalty for the partial flags register update.

	David

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

      reply	other threads:[~2021-11-15 10:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11  6:53 [RFC] x86/csum: rewrite csum_partial() Eric Dumazet
2021-11-11  9:10 ` Peter Zijlstra
2021-11-11  9:44   ` Peter Zijlstra
2021-11-11 16:02     ` Eric Dumazet
2021-11-11 16:52       ` Eric Dumazet
2021-11-11 18:17         ` Andrew Cooper
2021-11-11 19:02           ` Eric Dumazet
2021-11-11 16:51 ` Alexander Duyck
2021-11-14 13:07 ` David Laight
2021-11-14 14:12   ` David Laight
2021-11-15 10:23     ` David Laight [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e08af965e5b4422e9b38d8ccd90f8e7b@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.