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
On 12/1/20 1:37 PM, Randy Dunlap wrote:
> On 12/1/20 1:29 PM, Ard Biesheuvel wrote:
>> On Tue, 1 Dec 2020 at 20:53, Randy Dunlap wrote:
>>>
>>> On 12/1/20 2:03 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20201130:
>>>
>>> on i386 or x86_64:
>>>
>>> CONFIG_CRYPTO_AEGIS128=
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
On 12/1/20 1:29 PM, Ard Biesheuvel wrote:
> On Tue, 1 Dec 2020 at 20:53, Randy Dunlap wrote:
>>
>> On 12/1/20 2:03 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20201130:
>>>
>>
>> on i386 or x86_64:
>>
>> CONFIG_CRYPTO_AEGIS128=m
>> CONFIG_CRYPTO_AEGIS128_AESNI_SSE2=y
>>
>>
>> ERR
On Tue, 1 Dec 2020 at 20:53, Randy Dunlap wrote:
>
> On 12/1/20 2:03 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20201130:
> >
>
> on i386 or x86_64:
>
> CONFIG_CRYPTO_AEGIS128=m
> CONFIG_CRYPTO_AEGIS128_AESNI_SSE2=y
>
>
> ERROR: modpost: "crypto_aegis128_update_simd" [crypto/aeg
On 12/1/20 2:03 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20201130:
>
on i386 or x86_64:
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_AEGIS128_AESNI_SSE2=y
ERROR: modpost: "crypto_aegis128_update_simd" [crypto/aegis128.ko] undefined!
--
~Randy
Reported-by: Randy Dunlap
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(ctr(aes-aesni),aes-aesni) case in MAC calculation.
Suggested-by: Ben Greea
On Mon, 16 Nov 2020 18:58:44 +, Daniele Alessandrelli wrote:
> From: Declan Murphy
>
> Add device-tree bindings for the Intel Keem Bay Offload Crypto Subsystem
> (OCS) Hashing Control Unit (HCU) crypto driver.
>
> Signed-off-by: Declan Murphy
> Signed-off-by: Daniele Alessandrelli
> Acked-
On Tue, Dec 01 2020 at 15:45, Corentin Labbe wrote:
> On Tue, Dec 01, 2020 at 03:16:36PM +0100, Thomas Gleixner wrote:
> In fact the warn was a bit later so I added:
>preempt_disable();
> idx = arch_kmap_local_unmap_idx(kmap_local_idx(), addr);
> - WARN_ON_ONCE(addr != __fix_t
On Tue, Dec 01, 2020 at 03:16:36PM +0100, Thomas Gleixner wrote:
> On Tue, Dec 01 2020 at 14:52, Corentin Labbe wrote:
> > On Tue, Dec 01, 2020 at 02:28:54PM +0100, Thomas Gleixner wrote:
> > The patch made the board too busy logging and fail to boot until the test.
>
> Stupid me. Of course this w
On 11/30/20 10:32 PM, Ard Biesheuvel wrote:
On Mon, 30 Nov 2020 at 23:48, Ben Greear wrote:
On 11/29/20 10:20 AM, Ard Biesheuvel wrote:
From: Steve deRosier
Add ccm(aes) implementation from linux-wireless mailing list (see
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/12667
From: Marco Chiappero
Add logic to detect device capabilities in qat_4xxx driver.
Read fuses and build the device capabilities mask. This will enable
services and handling specific to QAT 4xxx devices.
Co-developed-by: Tomaszx Kowalik
Signed-off-by: Tomaszx Kowalik
Signed-off-by: Marco Chiapp
This set adds support for AES-CTR and AES-XTS for QAT GEN4 devices and
adds logic to detect and enable crypto capabilities in the qat_4xxx
driver.
Marco Chiappero (3):
crypto: qat - add AES-CTR support for QAT GEN4 devices
crypto: qat - add AES-XTS support for QAT GEN4 devices
crypto: qat -
From: Marco Chiappero
Add handling of AES-XTS specific to QAT GEN4 devices.
Co-developed-by: Tomaszx Kowalik
Signed-off-by: Tomaszx Kowalik
Signed-off-by: Marco Chiappero
Reviewed-by: Giovanni Cabiddu
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/qat_algs.c | 96 +++
From: Marco Chiappero
Add support for AES-CTR for QAT GEN4 devices.
Also, introduce the capability ICP_ACCEL_CAPABILITIES_AES_V2 and the
helper macro HW_CAP_AES_V2, which allow to distinguish between
different HW generations.
Co-developed-by: Tomasz Kowalik
Signed-off-by: Tomasz Kowalik
Co-dev
On Tue, Dec 01 2020 at 14:52, Corentin Labbe wrote:
> On Tue, Dec 01, 2020 at 02:28:54PM +0100, Thomas Gleixner wrote:
> The patch made the board too busy logging and fail to boot until the test.
Stupid me. Of course this wants to be conditional.
Thanks,
tglx
---
diff --git a/mm/
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it so
On Sun, Nov 22, 2020 at 08:17:03AM -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gusta
On Tue, Dec 01, 2020 at 02:28:54PM +0100, Thomas Gleixner wrote:
> On Tue, Dec 01 2020 at 14:01, Corentin Labbe wrote:
> > +[ 213.050152] [ cut here ]
> > +[ 213.050207] WARNING: CPU: 0 PID: 18430 at mm/highmem.c:581
> > kunmap_local_indexed+0x194/0x1d4
> > +[ 213.050214
On Tue, Dec 01 2020 at 14:01, Corentin Labbe wrote:
> +[ 213.050152] [ cut here ]
> +[ 213.050207] WARNING: CPU: 0 PID: 18430 at mm/highmem.c:581
> kunmap_local_indexed+0x194/0x1d4
> +[ 213.050214] Modules linked in: sm4_generic authenc vmac xcbc hmac
> streebog_generic
Hello
When testing 20201130, I hit this problem:
+[ 213.050152] [ cut here ]
+[ 213.050207] WARNING: CPU: 0 PID: 18430 at mm/highmem.c:581
kunmap_local_indexed+0x194/0x1d4
+[ 213.050214] Modules linked in: sm4_generic authenc vmac xcbc hmac
streebog_generic sm3_generi
On Mon, Nov 30, 2020 at 5:56 PM Theodore Y. Ts'o wrote:
> patches this cycle. One thing that would help me is if folks
> (especially Jason, if you would) could start with a detailed review of
> Nicolai's patches.
Sure, I'll take a look.
On Tue, Dec 01, 2020 at 09:12:38AM +, David Howells wrote:
>
> That depends on whether the caller has passed it elsewhere for some other
> parallel purpose, but I think I'm going to have to go down that road and
> restore it afterwards.
Sure but even if you added it to the API the underlying
Herbert Xu wrote:
> Couldn't you just change the output sg to include the offset?
That depends on whether the caller has passed it elsewhere for some other
parallel purpose, but I think I'm going to have to go down that road and
restore it afterwards.
David
On Tue, Dec 01, 2020 at 08:44:33AM +, David Howells wrote:
> Btw, would it be feasible to make it so that an extra parameter can be added
> to the cipher buffer-supplying functions, e.g.:
>
> skcipher_request_set_crypt(req, input, ciphertext_sg, esize, iv);
>
> such that we can pass in
Btw, would it be feasible to make it so that an extra parameter can be added
to the cipher buffer-supplying functions, e.g.:
skcipher_request_set_crypt(req, input, ciphertext_sg, esize, iv);
such that we can pass in an offset into the output sg as well?
David
On Mon, 30 Nov 2020 at 07:58, Tianjia Zhang
wrote:
>
>
>
> On 11/30/20 10:24 AM, Herbert Xu wrote:
> > On Mon, Nov 30, 2020 at 10:21:56AM +0800, Tianjia Zhang wrote:
> >>
> >>> That is true only if there are non-generic implementations of
> >>> the algorithms, which is not the case here. Please e
On Tue, Dec 01, 2020 at 12:52:27AM -0500, Martin K. Petersen wrote:
>
> Gustavo,
>
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
>
> Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks.
Awesome! :)
Thanks, Mart
42 matches
Mail list logo
