11:28 a.m.
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
11:47 a.m.
Stanislaw Gruszka (sgruszka(a)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
3:11 a.m.
On Fri, 2010-03-19 at 12:47 -0400, Bill Nottingham wrote:
Stanislaw Gruszka (sgruszka(a)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.
9:13 a.m.
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(a)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
8:30 p.m.
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
6:03 a.m.
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
8:30 p.m.
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
4:49 a.m.
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
11:07 p.m.
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
5143
days inactive
5150
days old
kernel@lists.fedoraproject.org
8 comments
4 participants
participants (4)
-
Bill Nottingham -
Jon Masters -
Stanislaw Gruszka -
Zhu Yi