On Tue, Dec 15, 2020 at 09:55:37AM +0100, Ard Biesheuvel wrote:
>
> So the question is then how granular these kernel mode SIMD regions
> need to be to avoid excessive latencies in softirq handling.
Can you get some real world numbers on what the latency is like?
Then we could take it to the sche
(+ Eric)
TL;DR can we find a way to use synchronous SIMD skciphers/aeads
without cryptd or scalar fallbacks
On Thu, 10 Dec 2020 at 13:19, Ard Biesheuvel wrote:
>
> On Thu, 10 Dec 2020 at 13:16, Herbert Xu wrote:
> >
> > On Thu, Dec 10, 2020 at 01:03:56PM +0100, Ard Biesheuvel wrote:
> > >
> > >
On 12/9/20 11:30 PM, Ard Biesheuvel wrote:
On Thu, 10 Dec 2020 at 04:01, Ben Greear wrote:
On 12/9/20 6:43 PM, Herbert Xu wrote:
On Thu, Dec 10, 2020 at 01:18:12AM +0100, Ard Biesheuvel wrote:
One thing I realized just now is that in the current situation, all
the synchronous skciphers alre
On Thu, 10 Dec 2020 at 13:16, Herbert Xu wrote:
>
> On Thu, Dec 10, 2020 at 01:03:56PM +0100, Ard Biesheuvel wrote:
> >
> > But we should probably start policing this a bit more. For instance, we now
> > have
> >
> > drivers/net/macsec.c:
> >
> > /* Pick a sync gcm(aes) cipher to ensure order is
On Thu, Dec 10, 2020 at 01:03:56PM +0100, Ard Biesheuvel wrote:
>
> But we should probably start policing this a bit more. For instance, we now
> have
>
> drivers/net/macsec.c:
>
> /* Pick a sync gcm(aes) cipher to ensure order is preserved. */
> tfm = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG
On Thu, 10 Dec 2020 at 12:14, Herbert Xu wrote:
>
> On Thu, Dec 10, 2020 at 08:30:47AM +0100, Ard Biesheuvel wrote:
> >
> > I would argue that these are orthogonal. My patch improves both the
> > accelerated and the fallback path, given that the latter does not have
> > to walk the input data twic
On Thu, Dec 10, 2020 at 08:30:47AM +0100, Ard Biesheuvel wrote:
>
> I would argue that these are orthogonal. My patch improves both the
> accelerated and the fallback path, given that the latter does not have
> to walk the input data twice anymore, and go through 3 layers of
> templates and the ass
On Thu, 10 Dec 2020 at 04:01, Ben Greear wrote:
>
> On 12/9/20 6:43 PM, Herbert Xu wrote:
> > On Thu, Dec 10, 2020 at 01:18:12AM +0100, Ard Biesheuvel wrote:
> >>
> >> One thing I realized just now is that in the current situation, all
> >> the synchronous skciphers already degrade like this.
> >>
On 12/9/20 6:43 PM, Herbert Xu wrote:
On Thu, Dec 10, 2020 at 01:18:12AM +0100, Ard Biesheuvel wrote:
One thing I realized just now is that in the current situation, all
the synchronous skciphers already degrade like this.
I.e., in Ben's case, without the special ccm implementation, ccm(aes)
w
On Thu, Dec 10, 2020 at 01:18:12AM +0100, Ard Biesheuvel wrote:
>
> One thing I realized just now is that in the current situation, all
> the synchronous skciphers already degrade like this.
>
> I.e., in Ben's case, without the special ccm implementation, ccm(aes)
> will resolve to ccm(ctr(aesni)
On Wed, 2 Dec 2020 at 00:12, Herbert Xu wrote:
>
> On Tue, Dec 01, 2020 at 11:27:52PM +0100, Ard Biesheuvel wrote:
> >
> > > The problem is that the degradation would come at the worst time,
> > > when the system is loaded. IOW when you get an interrupt during
> > > your TX path and get RX traffi
On 12/1/20 3:48 PM, Herbert Xu wrote:
On Wed, Dec 02, 2020 at 12:41:36AM +0100, Ard Biesheuvel wrote:
You just explained that TX typically runs in process context, whereas
RX is handled in softirq context. So how exactly are these going to
end up on the same core?
When you receive a TCP packe
On Wed, Dec 02, 2020 at 12:41:36AM +0100, Ard Biesheuvel wrote:
>
> You just explained that TX typically runs in process context, whereas
> RX is handled in softirq context. So how exactly are these going to
> end up on the same core?
When you receive a TCP packet via RX, this should wake up your
On Wed, 2 Dec 2020 at 00:30, Herbert Xu wrote:
>
> On Wed, Dec 02, 2020 at 12:24:47AM +0100, Ard Biesheuvel wrote:
> >
> > True. But the fallback only gets executed if the scheduler is stupid
> > enough to schedule the TX task onto the core that is overloaded doing
> > RX softirqs. So in the gener
On Wed, Dec 02, 2020 at 12:24:47AM +0100, Ard Biesheuvel wrote:
>
> True. But the fallback only gets executed if the scheduler is stupid
> enough to schedule the TX task onto the core that is overloaded doing
> RX softirqs. So in the general case, both TX and RX will be using
> AES-NI instructions
On Wed, 2 Dec 2020 at 00:12, Herbert Xu wrote:
>
> On Tue, Dec 01, 2020 at 11:27:52PM +0100, Ard Biesheuvel wrote:
> >
> > > The problem is that the degradation would come at the worst time,
> > > when the system is loaded. IOW when you get an interrupt during
> > > your TX path and get RX traffi
On Tue, Dec 01, 2020 at 11:27:52PM +0100, Ard Biesheuvel wrote:
>
> > The problem is that the degradation would come at the worst time,
> > when the system is loaded. IOW when you get an interrupt during
> > your TX path and get RX traffic that's when you'll take the fallback
> > path.
>
> I can
On Tue, 1 Dec 2020 at 23:16, Herbert Xu wrote:
>
> On Tue, Dec 01, 2020 at 11:12:32PM +0100, Ard Biesheuvel wrote:
> >
> > What do you mean by just one direction? Ben just confirmed a
>
> The TX direction generally executes in process context, which
> would benefit from an accelerated sync impleme
On Tue, Dec 01, 2020 at 11:12:32PM +0100, Ard Biesheuvel wrote:
>
> What do you mean by just one direction? Ben just confirmed a
The TX direction generally executes in process context, which
would benefit from an accelerated sync implementation. The RX
side on the other hand is always in softirq
On Tue, 1 Dec 2020 at 23:04, Herbert Xu wrote:
>
> On Tue, Dec 01, 2020 at 11:01:57PM +0100, Ard Biesheuvel wrote:
> >
> > This is not the first time this has come up. The point is that CCMP in
> > the wireless stack is not used in 99% of the cases, given that any
> > wifi hardware built in the la
On 12/1/20 2:04 PM, Herbert Xu wrote:
On Tue, Dec 01, 2020 at 11:01:57PM +0100, Ard Biesheuvel wrote:
This is not the first time this has come up. The point is that CCMP in
the wireless stack is not used in 99% of the cases, given that any
wifi hardware built in the last ~10 years can do it in
On Tue, Dec 01, 2020 at 11:01:57PM +0100, Ard Biesheuvel wrote:
>
> This is not the first time this has come up. The point is that CCMP in
> the wireless stack is not used in 99% of the cases, given that any
> wifi hardware built in the last ~10 years can do it in hardware. Only
> in exceptional ca
On Tue, 1 Dec 2020 at 22:57, Herbert Xu wrote:
>
> On Tue, Dec 01, 2020 at 08:45:56PM +0100, Ard Biesheuvel wrote:
> > Add ccm(aes) implementation from linux-wireless mailing list (see
> > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
> >
> > This eliminates FPU context s
On Tue, Dec 01, 2020 at 02:00:42PM -0800, Ben Greear wrote:
>
> No one wanted to do this for the last 6+ years, so I don't think it is likely
> to happen any time soon. If the patch is better than
> existing behaviour, please let it into the kernel. And it is certainly
> better in my test case.
On 12/1/20 1:57 PM, Herbert Xu wrote:
On Tue, Dec 01, 2020 at 08:45:56PM +0100, Ard Biesheuvel wrote:
Add ccm(aes) implementation from linux-wireless mailing list (see
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
This eliminates FPU context store/restore overhead exis
On Tue, Dec 01, 2020 at 08:45:56PM +0100, Ard Biesheuvel wrote:
> Add ccm(aes) implementation from linux-wireless mailing list (see
> http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).
>
> This eliminates FPU context store/restore overhead existing in more
> general ccm_base(c
This one works nicely on 5.8, and I assume later kernels as well. Thanks so
much
for seeing this through! I see 325Mbps tput on my test rig, and similar perf
top
to what the original patch showed.
Please add also:
Signed-off-by: Yauhen Kharuzhy
He worked on the version before Steve started
27 matches
Mail list logo
