Hi
I would like to change default iwlagn/iwl3945 options (swcrypto50=1 swcrypto=1) to solve two nasty iwlwifi firmware bugs.
What is preferred way to do this by changing /etc/modprobe.d/ or by patching kernel?
Stanislaw
Stanislaw Gruszka (sgruszka@redhat.com) said:
I would like to change default iwlagn/iwl3945 options (swcrypto50=1 swcrypto=1) to solve two nasty iwlwifi firmware bugs.
What is preferred way to do this by changing /etc/modprobe.d/ or by patching kernel?
If it's a temporary workaround, probably /etc/modprobe.d. If it's the way forward, just change the kernel (upstream!).
Bill
On Fri, 2010-03-19 at 12:47 -0400, Bill Nottingham wrote:
Stanislaw Gruszka (sgruszka@redhat.com) said:
I would like to change default iwlagn/iwl3945 options (swcrypto50=1 swcrypto=1) to solve two nasty iwlwifi firmware bugs.
What is preferred way to do this by changing /etc/modprobe.d/ or by patching kernel?
If it's a temporary workaround, probably /etc/modprobe.d. If it's the way forward, just change the kernel (upstream!).
Let us know what you need to be doing please.
Jon.
On Sun, Mar 21, 2010 at 04:11:53AM -0400, Jon Masters wrote:
On Fri, 2010-03-19 at 12:47 -0400, Bill Nottingham wrote:
Stanislaw Gruszka (sgruszka@redhat.com) said:
I would like to change default iwlagn/iwl3945 options (swcrypto50=1 swcrypto=1) to solve two nasty iwlwifi firmware bugs.
What is preferred way to do this by changing /etc/modprobe.d/ or by patching kernel?
If it's a temporary workaround, probably /etc/modprobe.d. If it's the way forward, just change the kernel (upstream!).
Let us know what you need to be doing please.
Using software encryption is workaround for firmware malfunction. We have two Fedora bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=519154 https://bugzilla.redhat.com/show_bug.cgi?id=556990 with many users affected. Many upstream users suffers from that problem as well.
Since this is firmware bug this should be fixed in firmware. Intel is aware of issue but we do not have F/W solution for that for long time.
Changing default options in upstream kernel is problematic. Since 2.6.33 we have different memory allocations to avoid failures due to buddy allocator fragmentation. It is optimized for normal usage case, but with swcrypto when and skb's have to be linearized memory usage by driver increase about 2 times.
So I would like to swcrypto options to fedora, and work for better solution upstream (or rather hope Intel will solve that).
Stanislaw
On Mon, 2010-03-22 at 22:13 +0800, Stanislaw Gruszka wrote:
Changing default options in upstream kernel is problematic. Since 2.6.33 we have different memory allocations to avoid failures due to buddy allocator fragmentation. It is optimized for normal usage case, but with swcrypto when and skb's have to be linearized memory usage by driver increase about 2 times.
Have you benchmarked about this change? Before paged Rx skb is used, we have to allocate (8K + sizeof(struct skb_shared_info)) linear skb, which is an order-2 allocation. Now with paged skb, first we do an order-1 allocation to hold the packet from device, then skb_linearize (if swcrypto is used) the skb. Note, in most of the time, the skb->len will be far less than 8K (unless 11n aggregation is used). So normally skb_linearize only does an order-1 (or even order-0) allocation in most. So in the swcrypto case, the paged Rx patch changes the memory allocation from one order-2 into two separated order-1 allocations. It should still be an improvement. No?
Thanks, -yi
On Tue, Mar 23, 2010 at 09:30:10AM +0800, Zhu Yi wrote:
On Mon, 2010-03-22 at 22:13 +0800, Stanislaw Gruszka wrote:
Changing default options in upstream kernel is problematic. Since 2.6.33 we have different memory allocations to avoid failures due to buddy allocator fragmentation. It is optimized for normal usage case, but with swcrypto when and skb's have to be linearized memory usage by driver increase about 2 times.
Have you benchmarked about this change?
No, not really.
Before paged Rx skb is used, we have to allocate (8K + sizeof(struct skb_shared_info)) linear skb, which is an order-2 allocation. Now with paged skb, first we do an order-1 allocation to hold the packet from device, then skb_linearize (if swcrypto is used) the skb. Note, in most of the time, the skb->len will be far less than 8K (unless 11n aggregation is used). So normally skb_linearize only does an order-1 (or even order-0) allocation in most. So in the swcrypto case, the paged Rx patch changes the memory allocation from one order-2 into two separated order-1 allocations. It should still be an improvement. No?
Ah, ok. So only additional cost with "paged Rx" and swcrypto is a memcpy, which is theoretically rather small cost compared with doing tx/rx cryptography in main cpu.
So, what about turn on swcrypto by default upstream?
Stanislaw
On Tue, 2010-03-23 at 19:03 +0800, Stanislaw Gruszka wrote:
Ah, ok. So only additional cost with "paged Rx" and swcrypto is a memcpy, which is theoretically rather small cost compared with doing tx/rx cryptography in main cpu.
So, what about turn on swcrypto by default upstream?
hwcrypto offloads cryptography to the device. It saves host CPU cycles so it's a good thing to do. The bug #519154 doesn't affect most people and only for 4965. #556990 doesn't look like swcrypto related, need to do more investigation. So I don't think we should use swcrypto=1 by default in upstream. Users are free to do so in their /etc/modprobe.d though.
Thanks, -yi
On Wed, Mar 24, 2010 at 09:30:24AM +0800, Zhu Yi wrote:
On Tue, 2010-03-23 at 19:03 +0800, Stanislaw Gruszka wrote:
Ah, ok. So only additional cost with "paged Rx" and swcrypto is a memcpy, which is theoretically rather small cost compared with doing tx/rx cryptography in main cpu.
So, what about turn on swcrypto by default upstream?
hwcrypto offloads cryptography to the device. It saves host CPU cycles so it's a good thing to do.
Have you did benchmarking ? :-P
Question is how swcrypto=1 hurts, does we have any valuable data for that?
The bug #519154 doesn't affect most people and only for 4965.
Don't like logic in that sentence.
#556990 doesn't look like swcrypto related, need to do more investigation.
User reported swcrypto=1 helps with it on 2.6.32.
So I don't think we should use swcrypto=1 by default in upstream. Users are free to do so in their /etc/modprobe.d though.
I think many users don't know about, and just live whit random crashes from time to time, or switch back to windows :-/
Stanislaw
On Wed, 2010-03-24 at 17:49 +0800, Stanislaw Gruszka wrote:
On Wed, Mar 24, 2010 at 09:30:24AM +0800, Zhu Yi wrote:
On Tue, 2010-03-23 at 19:03 +0800, Stanislaw Gruszka wrote:
Ah, ok. So only additional cost with "paged Rx" and swcrypto is a memcpy, which is theoretically rather small cost compared with doing tx/rx cryptography in main cpu.
So, what about turn on swcrypto by default upstream?
hwcrypto offloads cryptography to the device. It saves host CPU cycles so it's a good thing to do.
Have you did benchmarking ? :-P
Yeah, I remembered I did it on 3945 sometime (long) ago. It was about 5% CPU cycles save for CCMP/AES. It should also save the system power. But I forgot the number.
Question is how swcrypto=1 hurts, does we have any valuable data for that?
The bug #519154 doesn't affect most people and only for 4965.
Don't like logic in that sentence.
If I read the corresponding kernel bugzilla report correctly, this only affect to small portion of people.
#556990 doesn't look like swcrypto related, need to do more investigation.
User reported swcrypto=1 helps with it on 2.6.32.
See my comments in the bug. The issues should be both fixed in upstream.
So I don't think we should use swcrypto=1 by default in upstream. Users are free to do so in their /etc/modprobe.d though.
I think many users don't know about, and just live whit random crashes from time to time, or switch back to windows :-/
The windows driver also crashes. They just don't tell you about it. Do you want a "feature" like that in Linux? ;-)
Thanks, -yi
kernel@lists.fedoraproject.org
-
Bill Nottingham -
Jon Masters -
Stanislaw Gruszka -
Zhu Yi