From: David Laight <David.Laight@ACULAB.COM>
To: 'Eric Dumazet' <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>,
"Willem de Bruijn" <willemb@google.com>,
Neal Cardwell <ncardwell@google.com>,
"Yuchung Cheng" <ycheng@google.com>
Subject: RE: [RFC net-next] tcp: allow larger TSO to be built under overload
Date: Tue, 8 Mar 2022 22:12:06 +0000 [thread overview]
Message-ID: <218fd4946208411b90ac77cfcf7aa643@AcuMS.aculab.com> (raw)
In-Reply-To: <CANn89iL0XWF8aavPFnTrRazV9T5fZtn3xJXrEb07HTdrM=rykw@mail.gmail.com>
From: Eric Dumazet
> Sent: 08 March 2022 19:54
..
> > Which is the common side of that max_t() ?
> > If it is mon_tso_segs it might be worth avoiding the
> > divide by coding as:
> >
> > return bytes > mss_now * min_tso_segs ? bytes / mss_now : min_tso_segs;
> >
>
> I think the common case is when the divide must happen.
> Not sure if this really matters with current cpus.
Last document I looked at still quoted considerable latency
for integer divide on x86-64.
If you get a cmov then all the instructions will just get
queued waiting for the divide to complete.
But a branch could easily get mispredicted.
That is likely to hit ppc - which I don't think has a cmov?
OTOH if the divide is in the ?: bit nothing probably depends
on it for a while - so the latency won't matter.
Latest figures I have are for skylakeX
u-ops latency 1/throughput
DIV r8 10 10 p0 p1 p5 p6 23 6
DIV r16 10 10 p0 p1 p5 p6 23 6
DIV r32 10 10 p0 p1 p5 p6 26 6
DIV r64 36 36 p0 p1 p5 p6 35-88 21-83
IDIV r8 11 11 p0 p1 p5 p6 24 6
IDIV r16 10 10 p0 p1 p5 p6 23 6
IDIV r32 10 10 p0 p1 p5 p6 26 6
IDIV r64 57 57 p0 p1 p5 p6 42-95 24-90
Broadwell is a bit slower.
Note that 64bit divide is really horrid.
I think that one will be 32bit - so 'only' 26 clocks
latency.
AMD Ryzen is a lot better for 64bit divides:
ltncy 1/thpt
DIV r8/m8 1 13-16 13-16
DIV r16/m16 2 14-21 14-21
DIV r32/m32 2 14-30 14-30
DIV r64/m64 2 14-46 14-45
IDIV r8/m8 1 13-16 13-16
IDIV r16/m16 2 13-21 14-22
IDIV r32/m32 2 14-30 14-30
IDIV r64/m64 2 14-47 14-45
But less pipelining for 32bit ones.
Quite how those tables actually affect real code
is another matter - but they are guidelines about
what is possible (if you can get the u-ops executed
on the right ports).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-03-08 22:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-08 3:03 [RFC net-next] tcp: allow larger TSO to be built under overload Jakub Kicinski
2022-03-08 3:50 ` Eric Dumazet
2022-03-08 4:29 ` Jakub Kicinski
2022-03-08 9:07 ` David Laight
2022-03-08 19:53 ` Eric Dumazet
2022-03-08 22:12 ` David Laight [this message]
2022-03-08 22:26 ` Eric Dumazet
2022-03-08 22:42 ` Eric Dumazet
2022-03-09 0:18 ` Jakub Kicinski
2022-03-09 1:09 ` Eric Dumazet
2022-03-09 16:42 ` Neal Cardwell
2022-03-09 16:54 ` Jakub Kicinski
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=218fd4946208411b90ac77cfcf7aa643@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.com \
--cc=ycheng@google.com \
/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.