From: andrew@lunn•ch (Andrew Lunn)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
Date: Wed, 26 Sep 2018 16:36:14 +0200 [thread overview]
Message-ID: <20180926143614.GL1676@lunn.ch> (raw)
In-Reply-To: <CAHmME9r9KppoFwwNVpzpYbU+9dCPzb7Pit+4iRa4MY_ouJBWrA@mail.gmail.com>
> > Also, this still has unbounded worst case scheduling latency, given
> > that the outer library function passes its entire input straight into
> > the NEON routine.
>
> The vast majority of crypto routines in arch/*/crypto/ follow this
> same exact pattern, actually. I realize a few don't -- probably the
> ones you had a hand in :) -- but I think this is up to the caller to
> handle. I made a change so that in chacha20poly1305.c, it calls
> simd_relax after handling each scatter-gather element, so a
> "construction" will handle this gracefully. But I believe it's up to
> the caller to decide on what sizes of information it wants to pass to
> primitives. Put differently, this also hasn't ever been an issue
> before -- the existing state of the tree indicates this -- and so I
> don't anticipate this will be a real issue now. And if it becomes one,
> this is something we can address *later*, but certainly there's no use
> of adding additional complexity to the initial patchset to do this
> now.
Hi Jason
This is not my area of expertise, so you should verify what i'm say
here...
My guess is, IPSEC will mostly ask the crypto code to work on 1500
byte full MTU packets and 64 byte TCP ACK packets. Disk encryption i
guess works on 4K blocks. So these requests are all quite small,
keeping the latency reasonably bounded.
The wireguard interface claims it is GSO capable. This means the
network stack will pass it big chunks of data and leave it to the
network interface to perform the segmentation into 1500 byte MTU
frames on the wire. I've not looked at how wireguard actually handles
these big chunks. But to get maximum performance, it should try to
keep them whole, just add a header and/or trailer. Will wireguard pass
these big chunks of data to the crypto code? Do we now have 64K blocks
being worked on? Does the latency jump from 4K to 64K? That might be
new, so the existing state of the tree does not help you here.
Andrew
next prev parent reply other threads:[~2018-09-26 14:36 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180925145622.29959-1-Jason@zx2c4.com>
2018-09-25 14:56 ` [PATCH net-next v6 05/23] zinc: import Andy Polyakov's ChaCha20 ARM and ARM64 implementations Jason A. Donenfeld
[not found] ` <CAKv+Gu8-EwxFhQSUPxjEvTA5ZPz34RieMokM6CUqwURDr74jtg@mail.gmail.com>
2018-09-28 15:51 ` Ard Biesheuvel
2018-09-28 15:57 ` Jason A. Donenfeld
2018-09-25 14:56 ` [PATCH net-next v6 06/23] zinc: port " Jason A. Donenfeld
2018-09-25 14:56 ` [PATCH net-next v6 07/23] zinc: " Jason A. Donenfeld
2018-09-26 8:59 ` Ard Biesheuvel
2018-09-26 13:32 ` Jason A. Donenfeld
2018-09-26 14:02 ` Ard Biesheuvel
2018-09-26 15:41 ` Jason A. Donenfeld
2018-09-26 16:54 ` Ard Biesheuvel
2018-09-26 17:07 ` Jason A. Donenfeld
2018-09-26 17:37 ` Eric Biggers
2018-09-26 17:46 ` Jason A. Donenfeld
2018-09-26 15:41 ` Ard Biesheuvel
2018-09-26 15:45 ` Jason A. Donenfeld
2018-09-26 15:49 ` Jason A. Donenfeld
2018-09-26 15:51 ` Ard Biesheuvel
2018-09-26 15:58 ` Jason A. Donenfeld
2018-09-27 0:04 ` Jason A. Donenfeld
2018-09-27 13:26 ` Jason A. Donenfeld
2018-09-27 15:19 ` Jason A. Donenfeld
2018-09-27 16:26 ` Andy Lutomirski
2018-09-27 17:06 ` Jason A. Donenfeld
2018-09-26 16:21 ` Andy Lutomirski
2018-09-26 17:03 ` Jason A. Donenfeld
2018-09-26 17:08 ` Ard Biesheuvel
2018-09-26 17:23 ` Andy Lutomirski
2018-09-26 14:36 ` Andrew Lunn [this message]
2018-09-26 15:25 ` Jason A. Donenfeld
2018-09-28 16:01 ` Ard Biesheuvel
2018-09-29 2:20 ` Jason A. Donenfeld
2018-09-29 6:16 ` Ard Biesheuvel
2018-09-30 2:33 ` Jason A. Donenfeld
2018-09-25 14:56 ` [PATCH net-next v6 11/23] zinc: import Andy Polyakov's Poly1305 " Jason A. Donenfeld
2018-10-03 6:12 ` Eric Biggers
2018-10-03 7:58 ` Ard Biesheuvel
2018-10-03 14:08 ` Jason A. Donenfeld
2018-10-03 14:45 ` Jason A. Donenfeld
2018-09-25 14:56 ` [PATCH net-next v6 12/23] zinc: " Jason A. Donenfeld
2018-09-25 14:56 ` [PATCH net-next v6 19/23] zinc: Curve25519 ARM implementation Jason A. Donenfeld
2018-10-02 16:59 ` Ard Biesheuvel
2018-10-02 21:35 ` Richard Weinberger
2018-10-03 1:03 ` Jason A. Donenfeld
2018-10-05 15:05 ` D. J. Bernstein
2018-10-05 15:16 ` Ard Biesheuvel
2018-10-05 18:40 ` Jason A. Donenfeld
2018-10-03 3:10 ` Jason A. Donenfeld
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=20180926143614.GL1676@lunn.ch \
--to=andrew@lunn$(echo .)ch \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox