* Re: [PATCH 0/9]: TCP: The Road to Super TSO
From: Herbert Xu @ 2005-06-08 22:10 UTC (permalink / raw)
To: David S. Miller; +Cc: jheffner, netdev
In-Reply-To: <20050608.144906.77057282.davem@davemloft.net>
On Wed, Jun 08, 2005 at 02:49:06PM -0700, David S. Miller wrote:
>
> Performance went down, with both TSO enabled and disabled, compared to
> not having the patches applied.
What was the receiver running? Was the performance degradation more
pronounced with TSO enabled?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: [PATCH 0/9]: TCP: The Road to Super TSO
From: Leonid Grossman @ 2005-06-08 22:19 UTC (permalink / raw)
To: 'David S. Miller', jheffner; +Cc: netdev, herbert
In-Reply-To: <20050608.144906.77057282.davem@davemloft.net>
> -----Original Message-----
> From: netdev-bounce@oss.sgi.com
> [mailto:netdev-bounce@oss.sgi.com] On Behalf Of David S. Miller
> Sent: Wednesday, June 08, 2005 2:49 PM
> To: jheffner@psc.edu
> Cc: netdev@oss.sgi.com; herbert@gondor.apana.org.au
> Subject: Re: [PATCH 0/9]: TCP: The Road to Super TSO
>
> From: John Heffner <jheffner@psc.edu>
> Subject: Re: [PATCH 0/9]: TCP: The Road to Super TSO
> Date: Wed, 8 Jun 2005 17:40:10 -0400
>
> > On Tuesday 07 June 2005 12:08 am, David S. Miller wrote:
> > > Some folks, notable the S2IO guys, get performance
> degradation from
> > > the Super TSO v2 patch (they get it from the first
> version as well).
> > > It's a real pain to spot what causes such things in such a huge
> > > patch... so I started splitting things up in a very fine grained
> > > manner so we can catch regressions more precisely.
> >
> > I'm curious about the details of this. Is there decreased
> performance
> > relative to current TSO? Relative to no TSO? Sending to just one
> > receiver or many, and is it receiver limited?
>
> The receiver is limited in their tests. No current
> generation systems can fill a 10gbit pipe fully, especially
> at 1500 byte MTU.
With jumbo frames, a single receiver can handle 10GbE line rate.
With 1500 mtu, a single receiver becomes a bottleneck. I will forward the
numbers later today.
>
> Performance went down, with both TSO enabled and disabled,
> compared to not having the patches applied.
>
> That's why I'm going through this entire exercise of doing
> things one piece at a time.
>
>
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Pavel Machek @ 2005-06-08 22:34 UTC (permalink / raw)
To: James Ketrenos; +Cc: Jeff Garzik, Netdev list, kernel list, James P. Ketrenos
In-Reply-To: <42A76719.2060700@linux.intel.com>
Hi!
> >Having a parameter to control this seems a bit too complex to me.
> >
> >How is
> >
> >insmod ipw2100 enable=1
> >
> >different from
> >
> >insmod ipw2100
> >iwconfig eth1 start_scanning_or_whatever
> >
> >?
> It defaults to enabled, so you just need to do:
>
> insmod ipw2100
>
> and it will auto associate with an open network. For the use case where
> users want the device to load but not initialize, they can use
>
> insmod ipw2100 disable=1
>
> If hotplug and firmware loading worked early in the init sequence, no
> one would have issue with the current model; it works as users expect it
> to work. It magically finds and associates to networks, and your
> network scripts can then kick off DHCP, all with little to no special
> crafting or utility interfacing.
Actually it would still transmit when user did not want it to. I
believe that staying "quiet" is right thing, long-term. And it could
solve firmware-loading problems, short-term...
How long does association with AP take? Anyway it should be easy to
tell driver to associate ASAP, just after the insmod...
Pavel
^ permalink raw reply
* Re: netdev moved to vger; please subscribe
From: David S. Miller @ 2005-06-08 22:46 UTC (permalink / raw)
To: niv; +Cc: rdunlap, netdev
In-Reply-To: <42A77446.3030102@us.ibm.com>
From: Nivedita Singhvi <niv@us.ibm.com>
Date: Wed, 08 Jun 2005 15:42:14 -0700
> Is the intention to phase out netdev@oss.sgi.com gradually?
It should not be used any longer as of today. I'm changing
oss.sgi.com to vger.kernel.org in every posting I reply to.
^ permalink raw reply
* Re: [PATCH 1/1] sysctl configurable icmperror sourceaddress
From: Lennert Buytenhek @ 2005-06-08 23:40 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050608.144941.26530856.davem@davemloft.net>
On Wed, Jun 08, 2005 at 02:49:41PM -0700, David S. Miller wrote:
> > Can this patch go in, pretty please?
> >
> > Here's the patch again for reference:
>
> We have a similar sysctl for ARP handling, why don't
> we make use of it?
Which one do you mean, the arp_{filter,announce,ignore} ones? IMHO
this is a very different issue, this patch just selects which source
address we use when we reply to a packet with an ICMP.
In the case below, if all routers are linux routers, a traceroute
from source to dest will show something like this:
1 10.0.0.254 x.xxx ms x.xxx ms x.xxx ms
2 12.0.0.100 x.xxx ms x.xxx ms x.xxx ms
3 12.0.0.1 x.xxx ms x.xxx ms x.xxx ms
Whereas we'd prefer seeing this, partly because it makes more sense,
partly because a very large fraction of networking hardware does it
this way too:
1 10.0.0.254 x.xxx ms x.xxx ms x.xxx ms
2 11.0.0.100 x.xxx ms x.xxx ms x.xxx ms <===
3 12.0.0.1 x.xxx ms x.xxx ms x.xxx ms
I used to work at an ISP and there are a number of practical cases
where the linux behavior is rather confusing.
cheers,
Lennert
+------------+
| source |
| 10.0.0.1 |
+-----+------+
|
V
|
|
+-----+------+
| 10.0.0.254 |
| |
| router1 +---------------------+
| | |
| 11.0.0.254 | |
+-----+------+ |
| |
V ^ asymmetric route
| | back to source
| |
+-----+------+ +-----+------+
| 11.0.0.100 | | 13.0.0.13 |
| | | |
| router2 | | router3 |
| | | |
| 12.0.0.100 | | 12.0.0.101 |
+-----+------+ +-----+------+
| |
+------------->--------------+
V
|
+-----+------+
| dest |
| 12.0.0.1 |
+------------+
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Zhu Yi @ 2005-06-09 3:33 UTC (permalink / raw)
To: Pavel Machek
Cc: James Ketrenos, Jeff Garzik, Netdev list, kernel list,
James P. Ketrenos
In-Reply-To: <20050608223437.GB2614@elf.ucw.cz>
Hi Pavel,
On Thu, 2005-06-09 at 00:34 +0200, Pavel Machek wrote:
> Actually it would still transmit when user did not want it to. I
> believe that staying "quiet" is right thing, long-term. And it could
> solve firmware-loading problems, short-term...
If ipw2100 is built into kernel, you can disable it by kernel parameter
ipw2100.disable=1. Then you can enable it with:
$ echo 0 > /sys/bus/pci/drivers/ipw2100/*/rf_kill
> How long does association with AP take? Anyway it should be easy to
> tell driver to associate ASAP, just after the insmod...
Are you suggesting by default it is disabled for built into kernel but
enabled as a module?
Thanks,
-yi
^ permalink raw reply
* 2.6.12-rc6-mm1 OOPS in tcp_push_one()
From: Valdis.Kletnieks @ 2005-06-09 4:23 UTC (permalink / raw)
To: linux-kernel, netdev
[-- Attachment #1: Type: text/plain, Size: 3326 bytes --]
Am at home, running PPP over a modem. I get a request to push a patch to a
Sourceforge project I have CVS commit access to. So I do a 'export CVS_RSH=ssh'
and then do a 'cvs commit', and ker-blammo.
Very reproducible - this is about the 6th time in the past hour, always on
a cvs-over-ssh. Oddly enough, if I trigger it while logged on one of the
virtual consoles, I can c-a-f2 to another console, login, and run dmesg
to capture the wreckage. Doing it from an xterm window with the X server
running causes the system to lock up hard - I'm betting the oops dies with a
lock held, and the X server immediately hangs because it tries to do some
networking/socket stuff....
[17179956.772000] Unable to handle kernel paging request at virtual address a56b6b75
[17179956.776000] printing eip:
[17179956.788000] c0307f4c
[17179956.792000] *pde = 00000000
[17179956.804000] Oops: 0000 [#1]
[17179956.804000] PREEMPT
[17179956.804000] Modules linked in: ppp_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc tcp_bic orinoco_cs orinoco hermes pcmcia firmware_class ip_conntrack_ftp ipt_pkttype ipt_REJECT ipt_state ip_conntrack ipt_LOG ipt_limit ipt_u32 iptable_filter ip_tables ip6t_LOG ip6t_limit ip6table_filter ip6_tables thermal processor fan button battery ac i8k ohci1394 ieee1394 yenta_socket rsrc_nonstatic pcmcia_core intel_agp agpgart floppy
[17179956.804000] CPU: 0
[17179956.804000] EIP: 0060:[<c0307f4c>] Not tainted VLI
[17179956.804000] EFLAGS: 00010202 (2.6.12-rc6-mm1)
[17179956.804000] EIP is at tcp_transmit_skb+0x568/0x62b
[17179956.804000] eax: a56b6b6b ebx: 000004df ecx: 00000000 edx: c64de048
[17179956.804000] esi: c1ff2b88 edi: 00000001 ebp: c1c29dd4 esp: c1c29da0
[17179956.804000] ds: 007b es: 007b ss: 0068
[17179956.804000] Process ssh (pid: 2981, threadinfo=c1c28000 task=c3126a60)
[17179956.804000] Stack: c64de048 c64de080 00000020 00000000 c1ff2b88 c64deb88 c64debc0 c1c29dd4
[17179956.804000] c1fc71bc c64deb88 c1ff2b88 c64deb88 c64debc0 c1c29df4 c0308f8c 000005a8
[17179956.804000] 0001f742 00000001 c64deb88 c1ff2b88 000005a8 c1c29e5c c02ffba8 00000000
[17179956.804000] Call Trace:
[17179956.804000] [<c0103586>] show_stack+0x7a/0x83
[17179956.804000] [<c01036d6>] show_registers+0x130/0x1a1
[17179956.804000] [<c0103892>] die+0xd0/0x150
[17179956.804000] [<c0111930>] do_page_fault+0x454/0x5e0
[17179956.804000] [<c01031f3>] error_code+0x4f/0x54
[17179956.804000] [<c0308f8c>] tcp_push_one+0xea/0x190
[17179956.804000] [<c02ffba8>] tcp_sendmsg+0x71f/0x8f6
[17179956.804000] [<c0319c14>] inet_sendmsg+0x3c/0x49
[17179956.804000] [<c02de154>] sock_aio_write+0x117/0x124
[17179956.804000] [<c014e47d>] do_sync_write+0x89/0xb9
[17179956.804000] [<c014e56b>] vfs_write+0xbe/0x156
[17179956.804000] [<c014e69e>] sys_write+0x3b/0x60
[17179956.804000] [<c0102725>] syscall_call+0x7/0xb
[17179956.804000] Code: e0 04 8b 80 50 bb 4f c0 ff 40 2c 8b 8e d8 02 00 00 31 d2 8b 45 cc ff 11 89 c7 85 c0 0f 8e c2 00 00 00 8b 55 cc 8b 82 a4 00 00 00 <0f> b7 58 0a 66 c7 86 1a 03 00 00 00 00 80 be 26 02 00 00 01 0f
[17179956.804000]
This look familiar to anybody?
(On a related note, how did tcp_bic get loaded? I requested all the new
congestion stuff be built as modules, didn't specifically request any of
them to actually be loaded....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9]: TCP: The Road to Super TSO
From: Leonid Grossman @ 2005-06-09 4:30 UTC (permalink / raw)
To: 'David S. Miller'; +Cc: netdev
FYI, looks like the code in the nine patches is not responsible for the
performance drop; the problem is elsewhere in the Super TSO code.
-----Original Message-----
From: kshaw [mailto:kim.shaw@neterion.com]
Sent: Wednesday, June 08, 2005 8:34 PM
To: 'David S. Miller'
Cc: ravinandan.arakali@neterion.com; leonid.grossman@neterion.com
Subject: RE: test Super TSO
David,
I have applied all 9 patches (6-9 are done by editing source files), I don't
see Tx performance drop from any patch, Tx throughput remains at 6.17 Gb/s -
6.18 Gb/s.
The following is configuration:
4 way Opteron system .247 with shipping kernel 2.6.12-rc5 as TX system ,
4 way Opteron system .226 with kernel 2.6.11.5 as Rx system, NIC driver
REL_1-7-7-7_LX installed on both systems, Mtu is set to 9000 on both
systems.
Systems are connected back to back.
Run 8 nttcp connections from Tx system to Rx system for 60 seconds.
TSO is set to default on in both systems.
I also re-tested the original TSO patch which I used weeks ago,
With above same hardware, kernel 2.6.12-rc4 applied with original TSO patch
on Tx System, Tx throughput drops to 5.28 Gb/s.
^ permalink raw reply
* RE: [PATCH 0/9]: TCP: The Road to Super TSO
From: Leonid Grossman @ 2005-06-09 4:55 UTC (permalink / raw)
To: 'Herbert Xu', 'David S. Miller'; +Cc: jheffner, netdev
In-Reply-To: <20050608221047.GA12920@gondor.apana.org.au>
Some of the original data that we got couple weeks ago are attached.
On questions from Herbert and others:
- The performance drop from the "super-TSO" with TSO OFF is marginal, with
TSO ON
is quite noticeable.
- The numbers are similar in back-to-back and switch based (sender vs two
receivers) tests.
- The numbers are relative; we tested in pci-x 1.0 slots where ~7.5Gbps is a
practical bus limit
For TCP traffic. In pci-x 2.0 slots, the numbers are ~10Gbps with either
Jumbo frames
Or with 1500 mtu + TSO, (against two 1500 mtu receivers), at a fraction of a
single Opteron %cpu
- David is correct, with 1500 mtu the single receiver %cpu becomes a
bottleneck; the best throughput
with 1500 mtu I've seen was ~5Gbps. So, in B2B setup with 1500 mtu the
advantages of TSO are mostly wasted since there is no TSO counterpart on the
receive side.
Receive side stateless offloads fix this, but we did not get around to
deploy these ASIC capabilities in Linux yet.
Anyway, here it goes:
----------------------------------------------------------
Configuration:
Dual Opteron system .243 as Rx, dual Opteron system .117 as
Rx, four way Opteron system .247 as Tx, connected via CISCO switch.
.243 and .117 kernel source are patched with tcp_ack26.diff,
.247 kernel source are patched with tcp_super_tso.diff.
Run 8 nttcp connections from Tx system to each Rx system,
Use package size 65535 for mtu 1500,
Use package size 300000 for mtu 9000.
Tx throughput on four way Opteron system .247:
2.6.12-rc4
Tx-1500 CPU usage Tx-9000 CPU usage
---------------- ------------------
TSO off 2.5Gb/s 55%(note 1) 5.3 40%(3)
TSO on 4.0 47%(2) 6.1 35%(4)
==========================================================
2.6.12-rc4 with tcp_super_tso.diff patch
Tx-1500 CPU usage Tx-9000 CPU usage
---------------- ------------------
TSO off 2.4Gb/s 60%(5) 5.0 41%(7)
TSO on 3.5 45%(6) 5.7 35%(8)
Note(1):
1500 tso off
top - 08:45:41 up 13 min, 2 users, load average: 2.03, 1.01, 0.54
Tasks: 90 total, 3 running, 87 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0% us, 0.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 50.7% hi, 49.3% s
Cpu1 : 0.3% us, 29.2% sy, 0.0% ni, 53.2% id, 0.0% wa, 0.0% hi, 17.3% s
Cpu2 : 0.3% us, 27.9% sy, 0.0% ni, 53.2% id, 0.0% wa, 0.0% hi, 18.6% s
Cpu3 : 0.3% us, 23.6% sy, 0.0% ni, 59.5% id, 0.0% wa, 0.0% hi, 16.6% s
Mem: 2055724k total, 203172k used, 1852552k free, 24112k buffers
Swap: 2040244k total, 0k used, 2040244k free, 79384k cached
Note(2):
1500 tso on
top - 08:48:19 up 16 min, 2 users, load average: 0.74, 0.71, 0.49
Tasks: 90 total, 4 running, 86 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.3% us, 1.1% sy, 0.0% ni, 71.9% id, 0.6% wa, 12.2% hi, 13.8% s
Cpu1 : 0.5% us, 7.8% sy, 0.0% ni, 88.2% id, 0.5% wa, 0.0% hi, 3.0% s
Cpu2 : 0.4% us, 8.1% sy, 0.0% ni, 88.2% id, 0.5% wa, 0.0% hi, 2.9% s
Cpu3 : 0.3% us, 6.6% sy, 0.0% ni, 90.3% id, 0.1% wa, 0.0% hi, 2.7% s
Mem: 2055724k total, 203652k used, 1852072k free, 25308k buffers
Swap: 2040244k total, 0k used, 2040244k free, 79412k cached
Note(3):
9000 off
top - 08:58:19 up 6 min, 2 users, load average: 0.88, 0.47, 0.21
Tasks: 90 total, 2 running, 88 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.8% us, 8.8% sy, 0.0% ni, 79.1% id, 1.4% wa, 3.5% hi, 6.4% si
Cpu1 : 0.7% us, 7.3% sy, 0.0% ni, 90.8% id, 0.4% wa, 0.0% hi, 0.8% si
Cpu2 : 0.7% us, 6.9% sy, 0.0% ni, 90.8% id, 1.0% wa, 0.1% hi, 0.5% si
Cpu3 : 0.5% us, 5.1% sy, 0.0% ni, 93.9% id, 0.3% wa, 0.0% hi, 0.2% si
Mem: 2055724k total, 378620k used, 1677104k free, 18400k buffers
Swap: 2040244k total, 0k used, 2040244k free, 72788k cached
Note(4):
9000 on
top - 08:55:55 up 4 min, 2 users, load average: 0.53, 0.26, 0.12
Tasks: 90 total, 2 running, 88 sleeping, 0 stopped, 0 zombie
Cpu0 : 1.1% us, 4.4% sy, 0.0% ni, 89.2% id, 2.2% wa, 1.2% hi, 1.9% si
Cpu1 : 1.0% us, 3.5% sy, 0.0% ni, 94.3% id, 0.6% wa, 0.0% hi, 0.5% si
Cpu2 : 1.1% us, 6.4% sy, 0.0% ni, 90.7% id, 1.6% wa, 0.1% hi, 0.2% si
Cpu3 : 0.8% us, 5.3% sy, 0.0% ni, 93.5% id, 0.4% wa, 0.0% hi, 0.1% si
Mem: 2055724k total, 375892k used, 1679832k free, 17424k buffers
Swap: 2040244k total, 0k used, 2040244k free, 72676k cached
Note (5):
1500 tso off
top - 05:54:20 up 10 min, 2 users, load average: 1.48, 0.62, 0.29
Tasks: 91 total, 3 running, 88 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.5% us, 0.5% sy, 0.0% ni, 81.3% id, 0.9% wa, 7.6% hi, 9.1%
Cpu1 : 0.7% us, 5.4% sy, 0.0% ni, 91.5% id, 0.7% wa, 0.0% hi, 1.8%
Cpu2 : 0.6% us, 6.5% sy, 0.0% ni, 90.2% id, 0.7% wa, 0.0% hi, 2.0%
Cpu3 : 0.4% us, 5.5% sy, 0.0% ni, 92.1% id, 0.2% wa, 0.0% hi, 1.8%
Mem: 2055724k total, 204100k used, 1851624k free, 24056k buffers
Swap: 2040244k total, 0k used, 2040244k free, 79440k cached
Note (6):
1500 tso on
top - 05:49:36 up 6 min, 2 users, load average: 1.28, 0.45, 0.18
Tasks: 91 total, 6 running, 85 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0% us, 0.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 41.5% hi, 58.5%
Cpu1 : 0.0% us, 26.4% sy, 0.0% ni, 69.9% id, 0.0% wa, 0.0% hi, 3.7%
Cpu2 : 0.3% us, 24.3% sy, 0.0% ni, 71.3% id, 0.0% wa, 0.0% hi, 4.0%
Cpu3 : 0.0% us, 19.1% sy, 0.0% ni, 77.6% id, 0.0% wa, 0.0% hi, 3.3%
Mem: 2055724k total, 200496k used, 1855228k free, 22644k buffers
Swap: 2040244k total, 0k used, 2040244k free, 79288k cached
Note (7):
9000 off
top - 06:03:13 up 19 min, 2 users, load average: 0.52, 0.27, 0.23
Tasks: 91 total, 3 running, 88 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.3% us, 1.0% sy, 0.0% ni, 86.0% id, 0.5% wa, 5.3% hi, 6.8%
Cpu1 : 0.4% us, 4.3% sy, 0.0% ni, 93.7% id, 0.4% wa, 0.0% hi, 1.3%
Cpu2 : 0.3% us, 4.5% sy, 0.0% ni, 93.2% id, 0.4% wa, 0.0% hi, 1.5%
Cpu3 : 0.2% us, 3.8% sy, 0.0% ni, 94.7% id, 0.1% wa, 0.0% hi, 1.2%
Mem: 2055724k total, 399540k used, 1656184k free, 25816k buffers
Swap: 2040244k total, 0k used, 2040244k free, 79516k cached
Note (8):
9000 on
top - 06:05:16 up 21 min, 2 users, load average: 0.79, 0.42, 0.29
Tasks: 91 total, 1 running, 90 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.3% us, 2.5% sy, 0.0% ni, 83.5% id, 0.5% wa, 5.6% hi, 7.7%
Cpu1 : 0.4% us, 5.1% sy, 0.0% ni, 92.9% id, 0.3% wa, 0.0% hi, 1.3%
Cpu2 : 0.3% us, 4.9% sy, 0.0% ni, 92.9% id, 0.4% wa, 0.0% hi, 1.4%
Cpu3 : 0.2% us, 3.9% sy, 0.0% ni, 94.7% id, 0.1% wa, 0.0% hi, 1.2%
Mem: 2055724k total, 397784k used, 1657940k free, 26892k buffers
Swap: 2040244k total, 0k used, 2040244k free, 79528k cached
> -----Original Message-----
> From: netdev-bounce@oss.sgi.com
> [mailto:netdev-bounce@oss.sgi.com] On Behalf Of Herbert Xu
> Sent: Wednesday, June 08, 2005 3:11 PM
> To: David S. Miller
> Cc: jheffner@psc.edu; netdev@oss.sgi.com
> Subject: Re: [PATCH 0/9]: TCP: The Road to Super TSO
>
> On Wed, Jun 08, 2005 at 02:49:06PM -0700, David S. Miller wrote:
> >
> > Performance went down, with both TSO enabled and disabled,
> compared to
> > not having the patches applied.
>
> What was the receiver running? Was the performance
> degradation more pronounced with TSO enabled?
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
>
^ permalink raw reply
* Re: 2.6.12-rc6-mm1 OOPS in tcp_push_one()
From: David S. Miller @ 2005-06-09 5:58 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel, netdev
In-Reply-To: <200506090423.j594NWts004829@turing-police.cc.vt.edu>
From: Valdis.Kletnieks@vt.edu
Date: Thu, 09 Jun 2005 00:23:32 -0400
> (On a related note, how did tcp_bic get loaded? I requested all the new
> congestion stuff be built as modules, didn't specifically request any of
> them to actually be loaded....
It's the default algorithm, so when you open the first TCP
socket it tries to load it.
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-09 6:03 UTC (permalink / raw)
To: David S. Miller, jketreno
Cc: pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <20050608.124332.85408883.davem@davemloft.net>
On Wednesday 08 June 2005 22:43, David S. Miller wrote:
> From: James Ketrenos <jketreno@linux.intel.com>
> Date: Wed, 08 Jun 2005 12:10:37 -0500
>
> > My approach is to make the driver so it supports as many usage models as
> > possible, leaving policy to other components of the system.
>
> I don't see how this kind of firmware load setup handles something
> like an NFS root over such a device that requires firmware.
You practically cannot avoid having initrd because you are very likely
to need to do some wifi config (at least ESSID and mode).
Well, you can, but it gets more arcane with each turn
(essid=,mode= module parameters - in each and every wifi driver!
and what if you need to set basic rates? Yet another parameter?).
It's analogous to DHCP+NFS_root boot - we do have ugly hack
of kernelspace dhcp client, but IIRC it is agreed that the Right Thing
is to do such things in userspace (if needed, via initrd/initramfs).
It simply allows for way more options what you can do in early boot
if you have early userspace.
--
vda
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Jeff Garzik @ 2005-06-09 6:06 UTC (permalink / raw)
To: David S. Miller; +Cc: jketreno, vda, pavel, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <20050608.124332.85408883.davem@davemloft.net>
David S. Miller wrote:
> From: James Ketrenos <jketreno@linux.intel.com>
> Date: Wed, 08 Jun 2005 12:10:37 -0500
>
>
>>My approach is to make the driver so it supports as many usage models as
>>possible, leaving policy to other components of the system.
>
>
> I don't see how this kind of firmware load setup handles something
> like an NFS root over such a device that requires firmware.
>
> And let's not mention that I have to setup an initrd to make that
> work, that's rediculious.
>
> This is the kind of crap that happens when drivers in the kernel
> are not self contained, and need "external stuff" to work properly.
> It means that simple things like NFS root over the device do not
> work in a straightforward, simple, and elegant manner.
Actually these questions has already been answered (though I know you
will probably grumble a bit :))
"early userspace" is the long term answer. usr/* in the current kernel
tree is a placeholder for an image that is shipped with the kernel,
which provides things (kernel modules, userspace programs, firmware)
that are necessary to boot.
The key is that it is shipped with the kernel source tree, and built
into the kernel image, and _dropped from memory_ after init. The entire
process should all be automatic.
Linus ack'd the current stuff (by merging it, after some discussion) and
would have merged klibc too, had it any users.
...
As to $current_thread, initramfs exists but "early userspace" does not.
There isn't AFAIK any infrastructure to automatically add firmware
to initrd in any standard distribution (corrections welcome!). So
today, initrd+firmware is just a big pain.
Therefore, the easiest way to make things work today is to poke Intel to
fix their firmware license so that we can distribute it with the kernel :)
Jeff
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-09 6:09 UTC (permalink / raw)
To: abonilla, 'Pavel Machek', 'Jeff Garzik',
'Netdev list', 'kernel list',
'James P. Ketrenos'
In-Reply-To: <002901c56c3b$8216cdd0$600cc60a@amer.sykes.com>
On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
>
> > On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > > Hi!
> > >
> > > I'm fighting with firmware problem: if ipw2100 is compiled into
> > > kernel, it is loaded while kernel boots and firmware loader
> > is not yet
> > > available. That leads to uninitialized (=> useless) adapter.
>
> Pavel,
>
> I might be lost here but... How is the firmware loaded when using the
> ipw2100-1.0.0/patches Kernel patch?
>
> That patch normally works fine. It might not be the way you kernel
> developers would like it, but maybe that could work the same way?
>
>
> > >
> > > What's the prefered way to solve this one? Only load firmware when
> > > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > > better to start firmware sooner so that it can associate to the
> > > AP...].
> >
> > Do you want to associate to an AP when your kernel boots,
> > _before_ any iwconfig had a chance to configure anything?
> > That's strange.
>
> Currently, when we install the driver, it associates to any open network on
> boot. This is good, cause we don't want to be typing the commands all the
> time just to associate. It works this way now and is pretty nice.
What is so nice about this? That Linux novice user with his new lappie
will join a neighbor's network every time he powers up the lappie,
even without knowing that?
That will be analogous to me plugging ethernet cable into the switch and
wanting it to work, without any IP addr config, even without DHCP client.
Just power up the box (or modprobe an eth module) and it works! Cool, eh?
For some reason, we do not do this for wired nets. Why should wireless
be different?
--
vda
^ permalink raw reply
* Re: ipw2100: firmware problem
From: David S. Miller @ 2005-06-09 6:10 UTC (permalink / raw)
To: vda; +Cc: jketreno, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <200506090903.49295.vda@ilport.com.ua>
From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:03:49 +0300
> You practically cannot avoid having initrd because you are very likely
> to need to do some wifi config (at least ESSID and mode).
I need neither at home. It comes up by default just fine with
ifconfig.
Your points are valid, but they do not detract from the fact that
pieced up drivers, half in the kernel half somewhere else, is total
madness. It is a lose for the user.
^ permalink raw reply
* [PATCH] iseries_veth: Supress spurious WARN_ON() at module unload
From: Michael Ellerman @ 2005-06-09 6:11 UTC (permalink / raw)
To: Jeff Garzik, Andrew Morton; +Cc: netdev
Hi Andrew, Jeff,
My patch from a few weeks back (now in mainline), called
"Cleanup skbs to prevent unregister_netdevice() hanging", can cause
our TX timeout code to fire on machines with lots of VLANs (because
it takes > 2 seconds between when we stop the queues and when we're
finished stopping the connections).
When that happens the TX timeout code freaks out and does a WARN_ON()
because as far as it's concerned there shouldn't be a TX timeout
happening, which is fair enough.
I have a "proper" fix for this, which is to a) do refcounting on
connections and b) implement a proper ack timer so we don't keep unacked
skbs lying around for ever. But for 2.6.12 I propose just supressing
the WARN_ON(). Users will still see the "NETDEV WATCHDOG" warning,
but that's not nearly as bad as a WARN_ON() which users interpret
as an Oops.
cheers
--
Supress a spurious WARN_ON() in the iseries_veth driver which can
occur at module unload on machines with many VLANs.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -802,12 +802,13 @@
spin_lock_irqsave(&port->pending_gate, flags);
+ if (! port->pending_lpmask) {
+ spin_unlock_irqrestore(&port->pending_gate, flags);
+ return;
+ }
+
printk(KERN_WARNING "%s: Tx timeout! Resetting lp connections: %08x\n",
dev->name, port->pending_lpmask);
-
- /* If we've timed out the queue must be stopped, which should
- * only ever happen when there is a pending packet. */
- WARN_ON(! port->pending_lpmask);
for (i = 0; i < HVMAXARCHITECTEDLPS; i++) {
struct veth_lpar_connection *cnx = veth_cnx[i];
^ permalink raw reply
* Re: ipw2100: firmware problem
From: David S. Miller @ 2005-06-09 6:13 UTC (permalink / raw)
To: jgarzik; +Cc: jketreno, vda, pavel, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <42A7DC4D.7000008@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Thu, 09 Jun 2005 02:06:05 -0400
> Therefore, the easiest way to make things work today is to poke Intel to
> fix their firmware license so that we can distribute it with the kernel :)
Seperate firmware from the in-kernel driver is a big headache for
users. As DaveJ has stated, people make mistakes and try to match up
the wrong firmware version with the driver and stuff like that. And
he should know as he has to deal sift through bogus bug reports from
people running into this problem.
If it's integrated, there are no problems like this.
^ permalink raw reply
* Re: ipw2100: firmware problem
From: David S. Miller @ 2005-06-09 6:16 UTC (permalink / raw)
To: vda; +Cc: abonilla, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <200506090909.55889.vda@ilport.com.ua>
From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:09:55 +0300
> On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
> > Currently, when we install the driver, it associates to any open network on
> > boot. This is good, cause we don't want to be typing the commands all the
> > time just to associate. It works this way now and is pretty nice.
>
> What is so nice about this? That Linux novice user with his new lappie
> will join a neighbor's network every time he powers up the lappie,
> even without knowing that?
I love this behavior, because it means that I don't have to do
anything special to get my setup at home working.
Me caveman
Me plug in wireless router
Me watch pretty lights
Me turn on computer
Me up interface
Computer work
Me no care other cavemen use wireless link
Configuration knobs are _madness_. Things should work with minimal
intervention and configuration.
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-09 6:17 UTC (permalink / raw)
To: David S. Miller
Cc: jketreno, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <20050608.231045.48808548.davem@davemloft.net>
On Thursday 09 June 2005 09:10, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:03:49 +0300
>
> > You practically cannot avoid having initrd because you are very likely
> > to need to do some wifi config (at least ESSID and mode).
>
> I need neither at home. It comes up by default just fine with
> ifconfig.
>
> Your points are valid, but they do not detract from the fact that
> pieced up drivers, half in the kernel half somewhere else, is total
> madness. It is a lose for the user.
Here I am totally agree. I would like to not have to mess with
separate firmware files. I even don't want binary firmware, gimme
the source!
Sadly, realities are such that we have to live somehow
with closed-source firmware. Worse, sometimes it even isn't freely
redistributable (vendor did not explicitly allowed that),
and thus we have to ship driver, but users must obtain
firmware elsewhere themself.
Thus so far we cannot avoid having split drivers.
--
vda
^ permalink raw reply
* Re: ipw2100: firmware problem
From: David S. Miller @ 2005-06-09 6:20 UTC (permalink / raw)
To: vda; +Cc: jketreno, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <200506090917.23853.vda@ilport.com.ua>
From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:17:23 +0300
> Sadly, realities are such that we have to live somehow
> with closed-source firmware.
You have a choice, buy products from friendly vendors.
I use prism54 cards in my laptops for this reason.
If you like a vendor's products who aren't friendly, try
to voice intelligently your opinion to them as to why users
will benefit from them fixing the firmware situation.
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-09 6:25 UTC (permalink / raw)
To: David S. Miller
Cc: abonilla, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <20050608.231657.59660080.davem@davemloft.net>
On Thursday 09 June 2005 09:16, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:09:55 +0300
>
> > On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
> > > Currently, when we install the driver, it associates to any open network on
> > > boot. This is good, cause we don't want to be typing the commands all the
> > > time just to associate. It works this way now and is pretty nice.
> >
> > What is so nice about this? That Linux novice user with his new lappie
> > will join a neighbor's network every time he powers up the lappie,
> > even without knowing that?
>
> I love this behavior, because it means that I don't have to do
> anything special to get my setup at home working.
>
> Me caveman
> Me plug in wireless router
> Me watch pretty lights
> Me turn on computer
> Me up interface
You need to up interface? And surely you need ip addr? That's a knob also! :)
> Computer work
> Me no care other cavemen use wireless link
>
> Configuration knobs are _madness_. Things should work with minimal
> intervention and configuration.
Sure. I consider "iwconfig essid MyCave mode managed" a minimal intervention,
just like I consider "ip a a dev eth0 123.123.123.2/24 brd +; ip l set dev eth0 up"
a miniman interventian if I need IP configured.
--
vda
^ permalink raw reply
* Re: ipw2100: firmware problem
From: David S. Miller @ 2005-06-09 6:28 UTC (permalink / raw)
To: vda; +Cc: abonilla, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <200506090925.07495.vda@ilport.com.ua>
From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:25:07 +0300
> You need to up interface? And surely you need ip addr? That's a knob also! :)
There's this thing called DHCP which takes care of this for me.
With IPV6, even less configuration can be necessary.
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Jeff Garzik @ 2005-06-09 6:29 UTC (permalink / raw)
To: David S. Miller; +Cc: jketreno, vda, pavel, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <20050608.231319.95056824.davem@davemloft.net>
David S. Miller wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Thu, 09 Jun 2005 02:06:05 -0400
>
>
>>Therefore, the easiest way to make things work today is to poke Intel to
>>fix their firmware license so that we can distribute it with the kernel :)
>
>
> Seperate firmware from the in-kernel driver is a big headache for
> users. As DaveJ has stated, people make mistakes and try to match up
> the wrong firmware version with the driver and stuff like that. And
> he should know as he has to deal sift through bogus bug reports from
> people running into this problem.
>
> If it's integrated, there are no problems like this.
Early userspace is (a) shipped with the kernel source tree and (b)
linked into vmlinux. That's integrated.
The firmware images will be separate from the .c files (as they should
be), but the kernel hacker still controls what gets loaded, and when.
But like I said, that's where we're going, not where we are now.
Jeff
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-09 6:30 UTC (permalink / raw)
To: David S. Miller
Cc: jketreno, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <20050608.232020.115912376.davem@davemloft.net>
On Thursday 09 June 2005 09:20, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:17:23 +0300
>
> > Sadly, realities are such that we have to live somehow
> > with closed-source firmware.
>
> You have a choice, buy products from friendly vendors.
I am trying! So far, I have Prism2.5, Prism54
and acx111 cards, and all of them require closed binary fw.
> I use prism54 cards in my laptops for this reason.
?! As far as I remember, it needs a fw and fw is not open...
did that change recently?
> If you like a vendor's products who aren't friendly, try
> to voice intelligently your opinion to them as to why users
> will benefit from them fixing the firmware situation.
--
vda
^ permalink raw reply
* Re: ipw2100: firmware problem
From: David S. Miller @ 2005-06-09 6:35 UTC (permalink / raw)
To: vda; +Cc: jketreno, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <200506090930.22274.vda@ilport.com.ua>
From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:30:22 +0300
> On Thursday 09 June 2005 09:20, David S. Miller wrote:
> > I use prism54 cards in my laptops for this reason.
>
> ?! As far as I remember, it needs a fw and fw is not open...
> did that change recently?
My bad, they are not. You're right :-/
^ permalink raw reply
* Re: ipw2100: firmware problem
From: Denis Vlasenko @ 2005-06-09 6:37 UTC (permalink / raw)
To: David S. Miller
Cc: abonilla, pavel, jgarzik, netdev, linux-kernel, ipw2100-admin
In-Reply-To: <20050608.232818.31644993.davem@davemloft.net>
On Thursday 09 June 2005 09:28, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:25:07 +0300
>
> > You need to up interface? And surely you need ip addr? That's a knob also! :)
>
> There's this thing called DHCP which takes care of this for me.
> With IPV6, even less configuration can be necessary.
But DHCP does not start by itself, and it shuldn't.
You start dhcp client. That is a "minimal config" in this case.
Anyway, I think I start trolling... I should stop now.
--
vda
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox