From gnb@melbourne.sgi.com Wed Jun 1 01:17:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 01:17:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j518HRXq022082 for ; Wed, 1 Jun 2005 01:17:28 -0700 Received: from [134.14.55.176] (hole.melbourne.sgi.com [134.14.55.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA15672; Wed, 1 Jun 2005 18:16:26 +1000 Subject: Re: Locking model for NAPI drivers From: Greg Banks To: "David S. Miller" Cc: Linux Network Development list In-Reply-To: <20050531.154847.63995530.davem@davemloft.net> References: <20050531.154847.63995530.davem@davemloft.net> Content-Type: text/plain Organization: Silicon Graphics Inc, Australian Software Group. Message-Id: <1117613796.26331.2479.camel@hole.melbourne.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6-1mdk Date: Wed, 01 Jun 2005 18:16:36 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 1940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: netdev On Wed, 2005-06-01 at 08:48, David S. Miller wrote: > So the idea is, if we can make all of the spinlocks BH locks we'll > solve a whole bunch of problems: > [...] > 2) the driver will actually produce useful profiling data > via oprofile and friends since timer interrupts will run > even while holding the locks That would be really, really nice. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. From herbert@gondor.apana.org.au Wed Jun 1 01:44:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 01:44:09 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j518i1Xq023834 for ; Wed, 1 Jun 2005 01:44:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DdOoK-0005CB-00; Wed, 01 Jun 2005 18:42:48 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DdOoF-00082p-00; Wed, 01 Jun 2005 18:42:43 +1000 From: Herbert Xu To: ak@muc.de (Andi Kleen) Subject: Re: Locking model for NAPI drivers Cc: davem@davemloft.net, netdev@oss.sgi.com Organization: Core In-Reply-To: X-Newsgroups: apana.lists.os.linux.netdev User-Agent: tin/1.7.4-20040225 ("Benbecula") (UNIX) (Linux/2.4.27-hx-1-686-smp (i686)) Message-Id: Date: Wed, 01 Jun 2005 18:42:43 +1000 X-archive-position: 1941 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Andi Kleen wrote: > > That is because of the kmap_atomic it does right? At least in the i386 > highmem implementation I don't see any code that would be less safe in > hard interrupt context compared to BHs. And FRV and mips look like they > allow it too. To make it safe we'll have to allocate another precious km_type entry. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From raghunathan.venkatesan@wipro.com Wed Jun 1 04:40:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 04:41:12 -0700 (PDT) Received: from wip-ec-wd.wipro.com (wip-ec-wd.wipro.com [203.101.113.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51BepXq004532 for ; Wed, 1 Jun 2005 04:40:54 -0700 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 5CA9D205E4; Wed, 1 Jun 2005 17:00:54 +0530 (IST) Received: from blr-ec-bh01.wipro.com (unknown [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 3B276205E1; Wed, 1 Jun 2005 17:00:54 +0530 (IST) Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 17:09:48 +0530 Received: from CHN-SNR-MBX01.wipro.com ([10.145.50.181]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Jun 2005 17:04:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5669D.E951F95B" Subject: Unable to handle kernel paging request at virtual address 04000460 Date: Wed, 1 Jun 2005 17:01:23 +0530 Message-ID: <438662DA48DCAA41B1DF648BD4BD76C0E45DF1@CHN-SNR-MBX01.wipro.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Unable to handle kernel paging request at virtual address 04000460 Thread-Index: AcVgd+bKyjXc1BZZTzOXOhBhBJ2c9wAwfS0wAFOR2UABBPMC8A== From: To: , , X-OriginalArrivalTime: 01 Jun 2005 11:34:44.0715 (UTC) FILETIME=[E8897BB0:01C5669D] X-archive-position: 1942 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: raghunathan.venkatesan@wipro.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------_=_NextPart_001_01C5669D.E951F95B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everyone, We are facing the following crash in custom Linux 2.4.26 kernel, when we run a netperf TCP Stream (sizes varying from 64 to 32586 bytes) test over an IPSEC tunnel created between a host and a VPN server through our box. This is a Au1550 MIPS32 based board (DB1550 Cabernet board from AMD). We observe that crash happens randomly (the PrId keeps changing at each crash), because of burstiness in the netperf tool generated traffic. Please look into the following capture below. I'd like some help in debugging this issue. The same set of IPSEC drivers (not from Linux) works fine on a custom Linux 2.4.25 based kernel. We debugged the Oops traces and found that all problems arise in skbuff (donno where in skbuff). Is there a patch that needs to be applied for Linux 2.4.26 ?=20 Thanks & Regards, Raghu Venkatesan Project Manager (E & PE, Semiconductor & Access), CDC2, Sozhanganallur, Chennai - 600 119, INDIA +91 -44-24500200 Ext. 2643 raghunathan.venkatesan@wipro.com =20 ------_=_NextPart_001_01C5669D.E951F95B Content-Type: application/octet-stream; name="recent.cap_send1.oops" Content-Transfer-Encoding: base64 Content-Description: recent.cap_send1.oops Content-Disposition: attachment; filename="recent.cap_send1.oops" a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1 bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDIwMDA0 ZDQsIGVwYyA9PSA4MDI0YWY2YywgcmEgPT0gODAyNGIwOTQKT29wcyBpbiBmYXVsdC5jOjpkb19w YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAxMDAwZmMwMCA4YWJiYjYwMCAwMjAw MDQ2MCAwMjAwMDQ2MCA4YWJiYjVlYyAwMDAwMDAwMCAwMDAwMDVlYwokOCA6IDVhZDM0MzZlIDhh YmJiZGVjIGIzZGU1ZDcxIDU2NzM2OTg4IDA3ODNmZGZiIDgwMzIzODU4IDgwMzIzODA0IDI0ZTEy YWU1CiQxNjogMDIwMDA0NjAgMDAwMDAwMDEgOGFiYmI4MDAgMDAwMDA2MDAgMDAwMDBjZmMgMDAw MDA1ZGMgMDAwMDAwMTQgMDAwMDM0MDgKJDI0OiAwMDAwMDAwMCAyYWVhM2M3MCAgICAgICAgICAg ICAgICAgICA4MDMyMjAwMCA4MDMyM2EyOCAwMDAwMzQxYyA4MDI0YjA5NApIaSA6IDAwMDAwMDAw CkxvIDogMDAwMDA4MDAKZXBjICAgOiA4MDI0YWY2YyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBzd2FwcGVyIChwaWQ6IDAsIHN0YWNrcGFn ZT04MDMyMjAwMCkKU3RhY2s6ICAgIDhiOTYyNDgwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw IDAwMDAwODAwIDhiNmFmNDYwIDgwMjRiMDk0CiA4YjZhZjQ2MCA4YWJiYjgwMCAwMDAwMDYwMCAw MDAwMGNmYyAwMDAwMDVkYyAwMDAwMDgwMCA4YjZhZjQ2MCA4MDI0YjdjYwogODAyNGI3YjAgMjRl MTJhZTUgODAzMjM4NTggODAzMjM4MDQgYzAxYzIwNTAgOGI2YWY0NjAgODAzYTA0MDAgMDAwMDA1 YzgKIDgxMmJlMzAwIDgwMjUwMWQ0IDAwMDAwNWRjIDAwMDAwMDE0IDAwMDAyZTQwIDAwMDAwMDAw IDJhZWEzYzcwIDhiNmFmNDYwCiA4YWVhMTE2MCAwMDAwMDVjOCA4MDI2YTllOCAwMDAwMmU1NCA4 MDI2YTE4NCAxMDAwZmMwMyAwMDAwMDAwMCA4YjZhZjQ2MAogOGFiYmIwMTAgLi4uCkNhbGwgVHJh Y2U6ICAgWzw4MDI0YjA5ND5dIFs8ODAyNGI3Y2M+XSBbPDgwMjRiN2IwPl0gWzw4MDI1MDFkND5d IFs8ODAyNmE5ZTg+XQogWzw4MDI2YTE4ND5dIFs8ODAyNmEzMGM+XSBbPDgwMjZhMWRjPl0gWzw4 MDI2YTkwYz5dIFs8ODAyNmE5MGM+XSBbPDgwMjljNDE4Pl0KIFs8ODAyNmE5MGM+XSBbPDgwMjZh OTBjPl0gWzw4MDI1YTQ4ND5dIFs8ODAyNmE5MGM+XSBbPDgwMjZhOTBjPl0gWzw4MDI1YTk0OD5d CiBbPDgwMmRhMGUwPl0gWzw4MDI2YTkwYz5dIFs8ODAyNmE4ZDQ+XSBbPDgwMjZhOTBjPl0gWzw4 MDI2YTMwYz5dIFs8ODAyNmExODQ+XQogWzw4MDI2NzEzMD5dIFs8ODAyNjcxYjA+XSBbPDgwMjZh NzQ0Pl0gWzw4MDI1YTk4Yz5dIFs8ODAyOWVkODg+XSBbPDgwMjY3MTMwPl0KIFs8ODAyOWZkMzQ+ XSBbPDgwMjY3MDZjPl0gWzw4MDI2NzEzMD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1YTIwPl0gWzw4 MDI1YTQ4ND5dCiBbPGMwMWNlMmE4Pl0gWzw4MDI2NTdmOD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjVh OThjPl0gWzw4MDI1YTk0OD5dIC4uLgpXYXJuaW5nIChPb3BzX3RyYWNlX2xpbmUpOiBnYXJiYWdl ICcuLi4nIGF0IGVuZCBvZiB0cmFjZSBsaW5lIGlnbm9yZWQKQ29kZTogOGM1MDAwMDggIGFjNDAw MDA4ICAwMjAwMjAyMSA8OGM4MjAwNzQ+IDEwNTEwMDA5ICA4ZTEwMDAwMCAgYzA4MzAwNzQgIDAw NzExMDIzICBlMDgyMDA3NAoKCj4+UkE7ICAwMDAwMDAwMDgwMjRiMDk0IDxza2JfcmVsZWFzZV9k YXRhK2IwL2JjPgo+PiQxMzsgMDAwMDAwMDA4MDMyMzg1OCA8aW5pdF90YXNrX3VuaW9uKzE4NTgv MjAwMD4KPj4kMTQ7IDAwMDAwMDAwODAzMjM4MDQgPGluaXRfdGFza191bmlvbisxODA0LzIwMDA+ Cj4+JDI4OyAwMDAwMDAwMDgwMzIyMDAwIDxpbml0X3Rhc2tfdW5pb24rMC8yMDAwPgo+PiQyOTsg MDAwMDAwMDA4MDMyM2EyOCA8aW5pdF90YXNrX3VuaW9uKzFhMjgvMjAwMD4KPj4kMzE7IDAwMDAw MDAwODAyNGIwOTQgPHNrYl9yZWxlYXNlX2RhdGErYjAvYmM+Cgo+PlBDOyAgMDAwMDAwMDA4MDI0 YWY2YyA8c2tiX2Ryb3BfZnJhZ2xpc3QrMzQvNzQ+ICAgPD09PT09CgpUcmFjZTsgMDAwMDAwMDA4 MDI0YjA5NCA8c2tiX3JlbGVhc2VfZGF0YStiMC9iYz4KVHJhY2U7IDAwMDAwMDAwODAyNGI3Y2Mg PHNrYl9saW5lYXJpemUrYzQvMTRjPgpUcmFjZTsgMDAwMDAwMDA4MDI0YjdiMCA8c2tiX2xpbmVh cml6ZSthOC8xNGM+ClRyYWNlOyAwMDAwMDAwMDgwMjUwMWQ0IDxkZXZfcXVldWVfeG1pdCs1MC8z Yjg+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9maW5pc2hfb3V0cHV0MitlYy8xNTA+ClRy YWNlOyAwMDAwMDAwMDgwMjZhMTg0IDxpcF9mcmFnbWVudCsyNDAvNTAwPgpUcmFjZTsgMDAwMDAw MDA4MDI2YTMwYyA8aXBfZnJhZ21lbnQrM2M4LzUwMD4KVHJhY2U7IDAwMDAwMDAwODAyNmExZGMg PGlwX2ZyYWdtZW50KzI5OC81MDA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hf b3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0 MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjljNDE4IDxpcF9yZWZyYWcrNjgvNzQ+ClRyYWNl OyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAw MDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgw MjVhNDg0IDxuZl9pdGVyYXRlKzk0LzExND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2Zp bmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2ZpbmlzaF9v dXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgv MWY4PgpUcmFjZTsgMDAwMDAwMDA4MDJkYTBlMCA8bWVtc2V0KzAvMWM+ClRyYWNlOyAwMDAwMDAw MDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZh OGQ0IDxpcF9maW5pc2hfb3V0cHV0KzFhMC8xYTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxp cF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhMzBjIDxpcF9mcmFn bWVudCszYzgvNTAwPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTE4NCA8aXBfZnJhZ21lbnQrMjQwLzUw MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFj ZTsgMDAwMDAwMDA4MDI2NzFiMCA8aXBfZm9yd2FyZF9maW5pc2grOTAvYTA+ClRyYWNlOyAwMDAw MDAwMDgwMjZhNzQ0IDxpcF9maW5pc2hfb3V0cHV0KzEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAy NWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI5ZWQ4OCA8aXBf Y3RfcmVmcmVzaCs4NC9iOD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmlu aXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAwMDA4MDI5ZmQzNCA8aWNtcF9wYWNrZXQrOTgvOWM+ClRy YWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxfX2dudV9jb21waWxlZF9jKzI2Yy8zMjA+ClRyYWNlOyAw MDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAw ODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NWEyMCA8 aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0 ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMGMwMWNlMmE4IDxFTkRfT0ZfQ09ERSszZmUzYmFhOC8/ Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNl OyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAwMDAw ODAyNWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8 bmZfaG9va19zbG93KzEyOC8xZjg+CgpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2MCA8c2tiX2Ryb3Bf ZnJhZ2xpc3QrMjgvNzQ+CjAwMDAwMDAwIDxfUEM+OgpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2MCA8 c2tiX2Ryb3BfZnJhZ2xpc3QrMjgvNzQ+CiAgIDA6ICAgOGM1MDAwMDggIGx3ICAgICAgczAsOCh2 MCkKQ29kZTsgIDAwMDAwMDAwODAyNGFmNjQgPHNrYl9kcm9wX2ZyYWdsaXN0KzJjLzc0PgogICA0 OiAgIGFjNDAwMDA4ICBzdyAgICAgIHplcm8sOCh2MCkKQ29kZTsgIDAwMDAwMDAwODAyNGFmNjgg PHNrYl9kcm9wX2ZyYWdsaXN0KzMwLzc0PgogICA4OiAgIDAyMDAyMDIxICBtb3ZlICAgIGEwLHMw CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjZjIDxza2JfZHJvcF9mcmFnbGlzdCszNC83ND4gICA8PT09 PT0KICAgYzogICA4YzgyMDA3NCAgbHcgICAgICB2MCwxMTYoYTApICAgPD09PT09CkNvZGU7ICAw MDAwMDAwMDgwMjRhZjcwIDxza2JfZHJvcF9mcmFnbGlzdCszOC83ND4KICAxMDogICAxMDUxMDAw OSAgYmVxICAgICB2MCxzMSwzOCA8X1BDKzB4Mzg+CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjc0IDxz a2JfZHJvcF9mcmFnbGlzdCszYy83ND4KICAxNDogICA4ZTEwMDAwMCAgbHcgICAgICBzMCwwKHMw KQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY3OCA8c2tiX2Ryb3BfZnJhZ2xpc3QrNDAvNzQ+CiAgMTg6 ICAgYzA4MzAwNzQgIGxsICAgICAgdjEsMTE2KGEwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY3YyA8 c2tiX2Ryb3BfZnJhZ2xpc3QrNDQvNzQ+CiAgMWM6ICAgMDA3MTEwMjMgIHN1YnUgICAgdjAsdjEs czEKQ29kZTsgIDAwMDAwMDAwODAyNGFmODAgPHNrYl9kcm9wX2ZyYWdsaXN0KzQ4Lzc0PgogIDIw OiAgIGUwODIwMDc0ICBzYyAgICAgIHYwLDExNihhMCkKCktlcm5lbCBwYW5pYzogQWllZSwga2ls bGluZyBpbnRlcnJ1cHQgaGFuZGxlciEKCjEgd2FybmluZyBpc3N1ZWQuICBSZXN1bHRzIG1heSBu b3QgYmUgcmVsaWFibGUuCg== ------_=_NextPart_001_01C5669D.E951F95B Content-Type: application/octet-stream; name="recent.cap.oops" Content-Transfer-Encoding: base64 Content-Description: recent.cap.oops Content-Disposition: attachment; filename="recent.cap.oops" a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1 bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDQwMDA0 NjAsIGVwYyA9PSA4MDI0YjIwYywgcmEgPT0gODAyYzQ5ZjgKT29wcyBpbiBmYXVsdC5jOjpkb19w YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMSA4Yjc4MzU4MCAwMDAwMDAwMCAwNDAwMDQ2MCAwMDAwMDAwMQokOCA6IDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAyIGQzZDBiMDAwIDgwMzIzYjY4IDAwMDAwMDAwIDgwMzIzZDYwIDdiN2E3 OTc4CiQxNjogODEyYmViMjAgODEyYmViMjAgZmZmZmZmZmYgOGJiMGQ4MDAgODAzYTA4MDQgMDAw MDAwMDAgMDAwMDAwMDIgODAzMjNlMTAKJDI0OiAwMDAwMDAwMCAyYjAwYWM3MCAgICAgICAgICAg ICAgICAgICA4MDMyMjAwMCA4MDMyM2FkMCAwMDAwMjQwMSA4MDJjNDlmOApIaSA6IDAwMDAyMDkx CkxvIDogZDY5MTI4NWUKZXBjICAgOiA4MDI0YjIwYyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBzd2FwcGVyIChwaWQ6IDAsIHN0YWNrcGFn ZT04MDMyMjAwMCkKU3RhY2s6ICAgIDAwMDAwMDAwIDhiYjBkODAwIDgwM2EwODA0IDAwMDAwMDAw IDgxMmJlYjIwIDgwMmM0OWY4IDgwMTA3YzI4CiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCA4 MTJiZWIyMCA4MTI0ZmM2OCA4YjZhZjVhMCA4MDNhMDgwMCAwMDAwMDAwNAogODAyNTAwODggMDAw MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgODEyYjY1NjAgODAzYTA4MDAgOGI2YWY1 YTAKIDgwM2EwODAwIDAwMDAwMDAwIDgwMjVjM2UwIDAwMDAwMDAwIDAwMDAwMDAwIDgwMzIzYzE4 IDgwMzY5YmYwIDgwMzRkN2U4CiA4MDNhMDgwMCAwMDAwMDAwMCA4MDI1MDM3YyA4MDI5YzNlYyAw MDAwMDAwMCA4Yjc4MzU4MCA4YjZhZjVhMCAwMDAwMDAwZQogOGI2YWY1YTAgLi4uCkNhbGwgVHJh Y2U6ICAgWzw4MDJjNDlmOD5dIFs8ODAxMDdjMjg+XSBbPDgwMjUwMDg4Pl0gWzw4MDI1YzNlMD5d IFs8ODAyNTAzN2M+XQogWzw4MDI5YzNlYz5dIFs8ODAyNTczYTg+XSBbPDgwMjVhNDg0Pl0gWzw4 MDI2YTkwYz5dIFs8ODAyNmE5ZTg+XSBbPDgwMjZhOTBjPl0KIFs8ODAyNWE5OGM+XSBbPDgwMjVh OTQ4Pl0gWzw4MDI2YTkwYz5dIFs8ODAyYTNkOTg+XSBbPDgwMjY3MTMwPl0gWzw4MDI2YThkND5d CiBbPDgwMjZhOTBjPl0gWzw4MDI2NzFjMD5dIFs8ODAyNjcxMzA+XSBbPDgwMjVhOThjPl0gWzw4 MDI5Y2Y1MD5dIFs8ODAyNjcxMzA+XQogWzw4MDI5ZmQwND5dIFs8ODAyNjcwNmM+XSBbPDgwMjY3 MTMwPl0gWzw4MDI2NTdmOD5dIFs8ODAyNjVhMjA+XSBbPDgwMjVhNDg0Pl0KIFs8YzAxY2UyYTg+ XSBbPDgwMjY1N2Y4Pl0gWzw4MDI2NTdmOD5dIFs8ODAyNWE5OGM+XSBbPDgwMjVhOTQ4Pl0gWzw4 MDI2NTdmOD5dCiBbPDgwMjY1NWEwPl0gWzw4MDI2NTdmOD5dIFs8ODAyNTBkNDg+XSBbPDgwMmUw MWY0Pl0gWzw4MDEwN2MyOD5dIC4uLgpXYXJuaW5nIChPb3BzX3RyYWNlX2xpbmUpOiBnYXJiYWdl ICcuLi4nIGF0IGVuZCBvZiB0cmFjZSBsaW5lIGlnbm9yZWQKQ29kZTogOGUwNjAwOWMgIDEwYzAw MDBlICAyNDAzMDAwMSA8OGNjMjAwMDA+IGMwNDUwMDAwICAwMGEzMjAyMyAgZTA0NDAwMDAgIDEw ODBmZmZjICAwMGEzMjAyMwoKCj4+UkE7ICAwMDAwMDAwMDgwMmM0OWY4IDxwYWNrZXRfcmN2X3Nw a3QrMjljLzJiMD4KPj4kMTI7IDAwMDAwMDAwODAzMjNiNjggPGluaXRfdGFza191bmlvbisxYjY4 LzIwMDA+Cj4+JDE0OyAwMDAwMDAwMDgwMzIzZDYwIDxpbml0X3Rhc2tfdW5pb24rMWQ2MC8yMDAw Pgo+PiQyMzsgMDAwMDAwMDA4MDMyM2UxMCA8aW5pdF90YXNrX3VuaW9uKzFlMTAvMjAwMD4KPj4k Mjg7IDAwMDAwMDAwODAzMjIwMDAgPGluaXRfdGFza191bmlvbiswLzIwMDA+Cj4+JDI5OyAwMDAw MDAwMDgwMzIzYWQwIDxpbml0X3Rhc2tfdW5pb24rMWFkMC8yMDAwPgo+PiQzMTsgMDAwMDAwMDA4 MDJjNDlmOCA8cGFja2V0X3Jjdl9zcGt0KzI5Yy8yYjA+Cgo+PlBDOyAgMDAwMDAwMDA4MDI0YjIw YyA8X19rZnJlZV9za2IrYTQvMTMwPiAgIDw9PT09PQoKVHJhY2U7IDAwMDAwMDAwODAyYzQ5Zjgg PHBhY2tldF9yY3Zfc3BrdCsyOWMvMmIwPgpUcmFjZTsgMDAwMDAwMDA4MDEwN2MyOCA8ZG9fZ2V0 dGltZW9mZGF5KzU4LzExND4KVHJhY2U7IDAwMDAwMDAwODAyNTAwODggPGRldl9xdWV1ZV94bWl0 X25pdCtiYy8xMTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVjM2UwIDxfX2dudV9jb21waWxlZF9jKzcw LzE0Yz4KVHJhY2U7IDAwMDAwMDAwODAyNTAzN2MgPGRldl9xdWV1ZV94bWl0KzFmOC8zYjg+ClRy YWNlOyAwMDAwMDAwMDgwMjljM2VjIDxpcF9yZWZyYWcrM2MvNzQ+ClRyYWNlOyAwMDAwMDAwMDgw MjU3M2E4IDxuZWlnaF9yZXNvbHZlX291dHB1dCsxZmMvMjljPgpUcmFjZTsgMDAwMDAwMDA4MDI1 YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5p c2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9maW5pc2hfb3V0 cHV0MitlYy8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0Misx MC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJh Y2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFjZTsgMDAwMDAw MDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDJh M2Q5OCA8aXB0X2xvY2FsX291dF9ob29rKzQvOGM+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxp cF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNmE4ZDQgPGlwX2Zpbmlz aF9vdXRwdXQrMWEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2ZpbmlzaF9vdXRw dXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxYzAgPGlwX29wdGlvbnNfYnVpbGQrMC8w PgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAvYTA+ClRyYWNl OyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7IDAwMDAwMDAw ODAyOWNmNTAgPGRlYXRoX2J5X3RpbWVvdXQrM2MvYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMw IDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyOWZkMDQgPGljbXBf cGFja2V0KzY4LzljPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzA2YyA8X19nbnVfY29tcGlsZWRfYysy NmMvMzIwPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAvYTA+ ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAw MDAwMDAwODAyNjVhMjAgPGlwX3Jjdl9maW5pc2grMjM4LzJhOD4KVHJhY2U7IDAwMDAwMDAwODAy NWE0ODQgPG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDBjMDFjZTJhOCA8RU5EX09G X0NPREUrM2ZlM2JhYTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5p c2grMTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7IDAw MDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI2 NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1NWEwIDxpcF9y Y3YrNTEwLzU3OD4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4 PgpUcmFjZTsgMDAwMDAwMDA4MDI1MGQ0OCA8bmV0aWZfcmVjZWl2ZV9za2IrMjcwLzJjMD4KVHJh Y2U7IDAwMDAwMDAwODAyZTAxZjQgPGF1MTAwMF9JUlErMTM0LzFhMD4KVHJhY2U7IDAwMDAwMDAw ODAxMDdjMjggPGRvX2dldHRpbWVvZmRheSs1OC8xMTQ+CgpDb2RlOyAgMDAwMDAwMDA4MDI0YjIw MCA8X19rZnJlZV9za2IrOTgvMTMwPgowMDAwMDAwMCA8X1BDPjoKQ29kZTsgIDAwMDAwMDAwODAy NGIyMDAgPF9fa2ZyZWVfc2tiKzk4LzEzMD4KICAgMDogICA4ZTA2MDA5YyAgbHcgICAgICBhMiwx NTYoczApCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjA0IDxfX2tmcmVlX3NrYis5Yy8xMzA+CiAgIDQ6 ICAgMTBjMDAwMGUgIGJlcXogICAgYTIsNDAgPF9QQysweDQwPgpDb2RlOyAgMDAwMDAwMDA4MDI0 YjIwOCA8X19rZnJlZV9za2IrYTAvMTMwPgogICA4OiAgIDI0MDMwMDAxICBsaSAgICAgIHYxLDEK Q29kZTsgIDAwMDAwMDAwODAyNGIyMGMgPF9fa2ZyZWVfc2tiK2E0LzEzMD4gICA8PT09PT0KICAg YzogICA4Y2MyMDAwMCAgbHcgICAgICB2MCwwKGEyKSAgIDw9PT09PQpDb2RlOyAgMDAwMDAwMDA4 MDI0YjIxMCA8X19rZnJlZV9za2IrYTgvMTMwPgogIDEwOiAgIGMwNDUwMDAwICBsbCAgICAgIGEx LDAodjApCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjE0IDxfX2tmcmVlX3NrYithYy8xMzA+CiAgMTQ6 ICAgMDBhMzIwMjMgIHN1YnUgICAgYTAsYTEsdjEKQ29kZTsgIDAwMDAwMDAwODAyNGIyMTggPF9f a2ZyZWVfc2tiK2IwLzEzMD4KICAxODogICBlMDQ0MDAwMCAgc2MgICAgICBhMCwwKHYwKQpDb2Rl OyAgMDAwMDAwMDA4MDI0YjIxYyA8X19rZnJlZV9za2IrYjQvMTMwPgogIDFjOiAgIDEwODBmZmZj ICBiZXF6ICAgIGEwLDEwIDxfUEMrMHgxMD4KQ29kZTsgIDAwMDAwMDAwODAyNGIyMjAgPF9fa2Zy ZWVfc2tiK2I4LzEzMD4KICAyMDogICAwMGEzMjAyMyAgc3VidSAgICBhMCxhMSx2MQoKS2VybmVs IHBhbmljOiBBaWVlLCBraWxsaW5nIGludGVycnVwdCBoYW5kbGVyIQoKMSB3YXJuaW5nIGlzc3Vl ZC4gIFJlc3VsdHMgbWF5IG5vdCBiZSByZWxpYWJsZS4K ------_=_NextPart_001_01C5669D.E951F95B Content-Type: application/octet-stream; name="recent.cap_recv.oops" Content-Transfer-Encoding: base64 Content-Description: recent.cap_recv.oops Content-Disposition: attachment; filename="recent.cap_recv.oops" a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1 bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDAwMDMy NjAsIGVwYyA9PSA4MDI0YjIwYywgcmEgPT0gODAyYzQ5ZjgKT29wcyBpbiBmYXVsdC5jOjpkb19w YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMSA4Yjc4MDc2MCAwMDAwMDAwMCAwMDAwMzI2MCAwMDAwMDAwMQokOCA6IDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAyIGQzZDBiMDAwIGMwMTE1MDAwIDAwMDAxNGI4IDhiOWJmZDI4IDdiN2E3 OTc4CiQxNjogOGI2YjU0NjAgOGI2YjU0NjAgZmZmZmZmZmYgOGI5MGY4MDAgODAzYTA4MDQgMDAw MDAwMDAgMDAwMDAwMDIgOGI5YmZkZDgKJDI0OiAwMDAwMDAwMCAyYWNhZDU1MCAgICAgICAgICAg ICAgICAgICA4YjliZTAwMCA4YjliZmE5OCAwMDAwNDc5ZCA4MDJjNDlmOApIaSA6IDAwMDAyMzYx CkxvIDogNzY1MGYxMDgKZXBjICAgOiA4MDI0YjIwYyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyB2b3Nsb2cgKHBpZDogMTM0LCBzdGFja3Bh Z2U9OGI5YmUwMDApClN0YWNrOiAgICAwMDAwMDAwMCA4YjkwZjgwMCA4MDNhMDgwNCAwMDAwMDAw MCA4YjZiNTQ2MCA4MDJjNDlmOCA4MDEwN2MyOAogMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAg OGI2YjU0NjAgODEyNGZjNjggODEyYmVkMDAgODAzYTA4MDAgMDAwMDAwMDQKIDgwMjUwMDg4IDAw MDAwMDAwIDAwMDAwMDAwIDgwMjlkMzgwIDAwMDAwMDAwIDgxMmI2NTYwIDgwM2EwODAwIDgxMmJl ZDAwCiA4MDNhMDgwMCAwMDAwMDAwMCA4MDI1YzNlMCA4MDI2YTkwYyAwMDAwMDAwMyAwMDAwMDAw MiA4MDI5YzNhYyA4MDM0ZDdlOAogODAzYTA4MDAgMDAwMDAwMDAgODAyNTAzN2MgODAyOWMzZWMg MDAwMDAwMDAgOGI3ODA3NjAgODEyYmVkMDAgMDAwMDAwMGUKIDgxMmJlZDAwIC4uLgpDYWxsIFRy YWNlOiAgIFs8ODAyYzQ5Zjg+XSBbPDgwMTA3YzI4Pl0gWzw4MDI1MDA4OD5dIFs8ODAyOWQzODA+ XSBbPDgwMjVjM2UwPl0KIFs8ODAyNmE5MGM+XSBbPDgwMjljM2FjPl0gWzw4MDI1MDM3Yz5dIFs8 ODAyOWMzZWM+XSBbPDgwMjU3M2E4Pl0gWzw4MDI1YTQ4ND5dCiBbPDgwMjZhOTBjPl0gWzw4MDI2 YTllOD5dIFs8ODAyNmE5MGM+XSBbPDgwMjVhOThjPl0gWzw4MDI1YTk0OD5dIFs8ODAyNmE5MGM+ XQogWzw4MDJhM2Q5OD5dIFs8ODAyNjcxMzA+XSBbPDgwMjZhOGQ0Pl0gWzw4MDI2YTkwYz5dIFs8 ODAyNjcxYzA+XSBbPDgwMjY3MTMwPl0KIFs8ODAyNWE5OGM+XSBbPDgwMjY3MTMwPl0gWzw4MDI5 ZmQzND5dIFs8ODAyNjcwNmM+XSBbPDgwMjY3MTMwPl0gWzw4MDI2NTdmOD5dCiBbPDgwMjY1YTIw Pl0gWzw4MDI1YTQ4ND5dIFs8YzAxY2UyYTg+XSBbPDgwMjY1N2Y4Pl0gWzw4MDI2NTdmOD5dIFs8 ODAyNWE5OGM+XQogWzw4MDI1YTk0OD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1NWEwPl0gWzw4MDI2 NTdmOD5dIFs8ODAxMDEzM2M+XSAuLi4KV2FybmluZyAoT29wc190cmFjZV9saW5lKTogZ2FyYmFn ZSAnLi4uJyBhdCBlbmQgb2YgdHJhY2UgbGluZSBpZ25vcmVkCkNvZGU6IDhlMDYwMDljICAxMGMw MDAwZSAgMjQwMzAwMDEgPDhjYzIwMDAwPiBjMDQ1MDAwMCAgMDBhMzIwMjMgIGUwNDQwMDAwICAx MDgwZmZmYyAgMDBhMzIwMjMKCgo+PlJBOyAgMDAwMDAwMDA4MDJjNDlmOCA8cGFja2V0X3Jjdl9z cGt0KzI5Yy8yYjA+Cj4+JDMxOyAwMDAwMDAwMDgwMmM0OWY4IDxwYWNrZXRfcmN2X3Nwa3QrMjlj LzJiMD4KCj4+UEM7ICAwMDAwMDAwMDgwMjRiMjBjIDxfX2tmcmVlX3NrYithNC8xMzA+ICAgPD09 PT09CgpUcmFjZTsgMDAwMDAwMDA4MDJjNDlmOCA8cGFja2V0X3Jjdl9zcGt0KzI5Yy8yYjA+ClRy YWNlOyAwMDAwMDAwMDgwMTA3YzI4IDxkb19nZXR0aW1lb2ZkYXkrNTgvMTE0PgpUcmFjZTsgMDAw MDAwMDA4MDI1MDA4OCA8ZGV2X3F1ZXVlX3htaXRfbml0K2JjLzExMD4KVHJhY2U7IDAwMDAwMDAw ODAyOWQzODAgPF9faXBfY29ubnRyYWNrX2NvbmZpcm0rMjM4LzJjOD4KVHJhY2U7IDAwMDAwMDAw ODAyNWMzZTAgPF9fZ251X2NvbXBpbGVkX2MrNzAvMTRjPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkw YyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI5YzNhYyA8aXBf Y29uZmlybSs0OC80Yz4KVHJhY2U7IDAwMDAwMDAwODAyNTAzN2MgPGRldl9xdWV1ZV94bWl0KzFm OC8zYjg+ClRyYWNlOyAwMDAwMDAwMDgwMjljM2VjIDxpcF9yZWZyYWcrM2MvNzQ+ClRyYWNlOyAw MDAwMDAwMDgwMjU3M2E4IDxuZWlnaF9yZXNvbHZlX291dHB1dCsxZmMvMjljPgpUcmFjZTsgMDAw MDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBj IDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOWU4IDxpcF9m aW5pc2hfb3V0cHV0MitlYy8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hf b3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZj LzFmOD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5NDggPG5mX2hvb2tfc2xvdysxMjgvMWY4PgpUcmFj ZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAw MDAwMDA4MDJhM2Q5OCA8aXB0X2xvY2FsX291dF9ob29rKzQvOGM+ClRyYWNlOyAwMDAwMDAwMDgw MjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNmE4ZDQg PGlwX2ZpbmlzaF9vdXRwdXQrMWEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlwX2Zp bmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNjcxYzAgPGlwX29wdGlvbnNf YnVpbGQrMC8wPgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5pc2grMTAv YTA+ClRyYWNlOyAwMDAwMDAwMDgwMjVhOThjIDxuZl9ob29rX3Nsb3crMTZjLzFmOD4KVHJhY2U7 IDAwMDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAw MDA4MDI5ZmQzNCA8aWNtcF9wYWNrZXQrOTgvOWM+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxf X2dudV9jb21waWxlZF9jKzI2Yy8zMjA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3 YXJkX2ZpbmlzaCsxMC9hMD4KVHJhY2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2gr MTAvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NWEyMCA8aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpU cmFjZTsgMDAwMDAwMDA4MDI1YTQ4NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAw MGMwMWNlMmE4IDxFTkRfT0ZfQ09ERSszZmUzYmFhOC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2 NTdmOCA8aXBfcmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9y Y3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hvb2tfc2xvdysx NmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRy YWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJhY2U7IDAwMDAw MDAwODAyNjU1YTAgPGlwX3Jjdis1MTAvNTc4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBf cmN2X2ZpbmlzaCsxMC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMTAxMzNjIDxkb19JUlErZjQvMTE4 PgoKQ29kZTsgIDAwMDAwMDAwODAyNGIyMDAgPF9fa2ZyZWVfc2tiKzk4LzEzMD4KMDAwMDAwMDAg PF9QQz46CkNvZGU7ICAwMDAwMDAwMDgwMjRiMjAwIDxfX2tmcmVlX3NrYis5OC8xMzA+CiAgIDA6 ICAgOGUwNjAwOWMgIGx3ICAgICAgYTIsMTU2KHMwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YjIwNCA8 X19rZnJlZV9za2IrOWMvMTMwPgogICA0OiAgIDEwYzAwMDBlICBiZXF6ICAgIGEyLDQwIDxfUEMr MHg0MD4KQ29kZTsgIDAwMDAwMDAwODAyNGIyMDggPF9fa2ZyZWVfc2tiK2EwLzEzMD4KICAgODog ICAyNDAzMDAwMSAgbGkgICAgICB2MSwxCkNvZGU7ICAwMDAwMDAwMDgwMjRiMjBjIDxfX2tmcmVl X3NrYithNC8xMzA+ICAgPD09PT09CiAgIGM6ICAgOGNjMjAwMDAgIGx3ICAgICAgdjAsMChhMikg ICA8PT09PT0KQ29kZTsgIDAwMDAwMDAwODAyNGIyMTAgPF9fa2ZyZWVfc2tiK2E4LzEzMD4KICAx MDogICBjMDQ1MDAwMCAgbGwgICAgICBhMSwwKHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YjIxNCA8 X19rZnJlZV9za2IrYWMvMTMwPgogIDE0OiAgIDAwYTMyMDIzICBzdWJ1ICAgIGEwLGExLHYxCkNv ZGU7ICAwMDAwMDAwMDgwMjRiMjE4IDxfX2tmcmVlX3NrYitiMC8xMzA+CiAgMTg6ICAgZTA0NDAw MDAgIHNjICAgICAgYTAsMCh2MCkKQ29kZTsgIDAwMDAwMDAwODAyNGIyMWMgPF9fa2ZyZWVfc2ti K2I0LzEzMD4KICAxYzogICAxMDgwZmZmYyAgYmVxeiAgICBhMCwxMCA8X1BDKzB4MTA+CkNvZGU7 ICAwMDAwMDAwMDgwMjRiMjIwIDxfX2tmcmVlX3NrYitiOC8xMzA+CiAgMjA6ICAgMDBhMzIwMjMg IHN1YnUgICAgYTAsYTEsdjEKCktlcm5lbCBwYW5pYzogQWllZSwga2lsbGluZyBpbnRlcnJ1cHQg aGFuZGxlciEKCjEgd2FybmluZyBpc3N1ZWQuICBSZXN1bHRzIG1heSBub3QgYmUgcmVsaWFibGUu Cg== ------_=_NextPart_001_01C5669D.E951F95B Content-Type: application/octet-stream; name="recent.cap_send.oops" Content-Transfer-Encoding: base64 Content-Description: recent.cap_send.oops Content-Disposition: attachment; filename="recent.cap_send.oops" a3N5bW9vcHMgMi40Ljkgb24gaTY4NiAyLjQuMjItMS4yMTE1Lm5wdGwuICBPcHRpb25zIHVzZWQK ICAgICAtdiAvaG9tZS9hbWQvcHJvamVjdC9hbWQva2VybmVsL3ZtbGludXggKGRlZmF1bHQpCiAg ICAgLUsgKHNwZWNpZmllZCkKICAgICAtbCAvcHJvYy9tb2R1bGVzIChkZWZhdWx0KQogICAgIC1v IC9ob21lL2FtZC9wcm9qZWN0L2FtZC9maWxlc3lzdGVtL3Vzci9saWIvbW9kdWxlcy8gKGRlZmF1 bHQpCiAgICAgLW0gL2hvbWUvYW1kL3Byb2plY3QvYW1kL2tlcm5lbC9TeXN0ZW0ubWFwIChkZWZh dWx0KQogICAgIC10IGVsZjMyLWxpdHRsZW1pcHMgLWEgbWlwczo0NjAwCgpObyBtb2R1bGVzIGlu IGtzeW1zLCBza2lwcGluZyBvYmplY3RzCk5vIGtzeW1zLCBza2lwcGluZyBsc21vZApVbmFibGUg dG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDAwMDMy ZDQsIGVwYyA9PSA4MDI0YWY2YywgcmEgPT0gODAyNGIwOTQKT29wcyBpbiBmYXVsdC5jOjpkb19w YWdlX2ZhdWx0LCBsaW5lIDIwNjoKJDAgOiAwMDAwMDAwMCAxMDAwZmMwMCA4YWM4MWUwMCAwMDAw MzI2MCAwMDAwMzI2MCAwMDAwMDAwMCAwMDAwMDAwMCA4YjM4YjM0MAokOCA6IDAwMDAwMDMwIDgw MmRhMWEwIDAwMDAwMDEwIGJmYmViZGJjIGEzYTJhMWEwIDAwMDAwMDAwIDhhYjc5ZGU4IGE3YTZh NWE0CiQxNjogMDAwMDMyNjAgMDAwMDAwMDEgOGFlYTgyNjAgYzAxNzI5NGMgMDAwMDAwMGYgODAy NGIxNzggYzAxNjdhYjggYzAxNzI5NTAKJDI0OiAwMDAwMDAxMCAwMDQwZTBmMCAgICAgICAgICAg ICAgICAgICA4YWI3ODAwMCA4YWI3OWE2OCBjMDE3MjdkOCA4MDI0YjA5NApIaSA6IDAwMDAwMDAw CkxvIDogMDAwMDAwMGIKZXBjICAgOiA4MDI0YWY2YyAgICBOb3QgdGFpbnRlZApTdGF0dXM6IDEw MDBmYzAzCkNhdXNlIDogMDA4MDAwMDgKUHJvY2VzcyBtZG0td2lwcm8tbm8tZGUgKHBpZDogNDEw LCBzdGFja3BhZ2U9OGFiNzgwMDApClN0YWNrOiAgICA4YWI3OWFkOCA4MDM2OWJmMCAwMDAwMDAw NCA4MDI1YTQ4NCA4YjZiNTQ2MCA4YjZiNTQ2MCA4MDI0YjA5NAogZmZmYmM0NzMgODAyNmE5MGMg ODAzYTA0MDAgODEyYmVhODAgODAzYTA0MDAgOGI2YjU0NjAgOGIzOGIzNjAgODAyNGIwYzQKIDAw MDAwMDAwIDAwMDAwMDAyIDAwMDA0MGQyIDgwMmRhMGUwIDhhYjc5YzU4IDhiNmI1NDYwIDgwMjRi Mjk4IDgxMmI2NDYwCiA4MDNhMDQwMCA4MDNhMDQwMCA4YWI3OWFkOCA4YjZiNTQ2MCBjMDE3MWY1 OCA4MTJiZWJjMCA4MDM5MDZhOCAwMDAwMDAyMAogODAyNGFlMzggOGI2YjU3ODAgOGFhYzQwZjYg OGI0MjhkNjAgMDAwMDAwMDAgODEyYmViYzAgOGFhYzAwMTAgOGFlYTgyNjAKIDAwMDA0MGQyIC4u LgpDYWxsIFRyYWNlOiAgIFs8ODAyNWE0ODQ+XSBbPDgwMjRiMDk0Pl0gWzw4MDI2YTkwYz5dIFs8 ODAyNGIwYzQ+XSBbPDgwMmRhMGUwPl0KIFs8ODAyNGIyOTg+XSBbPGMwMTcxZjU4Pl0gWzw4MDI0 YWUzOD5dIFs8ODAyZDlkODA+XSBbPGMwMTcxZTEwPl0gWzw4MDI2YTkwYz5dCiBbPGMwMTcyNDE0 Pl0gWzxjMDE3NDBlOD5dIFs8ODAyNWE0ODQ+XSBbPDgwMjZhOTBjPl0gWzw4MDI2YTkwYz5dIFs8 ODAyNWE5NDg+XQogWzw4MDJkYTBlMD5dIFs8ODAyNmE5MGM+XSBbPGMwMTc1MWRjPl0gWzw4MDI2 YThkND5dIFs8ODAyNmE5MGM+XSBbPDgwMjZhMzBjPl0KIFs8ODAyNmExODQ+XSBbPDgwMjY3MTMw Pl0gWzw4MDI2NzFiMD5dIFs8ODAyNmE3NDQ+XSBbPDgwMjVhOThjPl0gWzw4MDI2NzEzMD5dCiBb PDgwMjY3MDZjPl0gWzw4MDI2NzEzMD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjY1YTIwPl0gWzw4MDI1 YTQ4ND5dIFs8YzAxY2UyYTg+XQogWzw4MDI2NTdmOD5dIFs8ODAyNjU3Zjg+XSBbPDgwMjVhOThj Pl0gWzw4MDI1YTk0OD5dIFs8ODAyNjU3Zjg+XSAuLi4KV2FybmluZyAoT29wc190cmFjZV9saW5l KTogZ2FyYmFnZSAnLi4uJyBhdCBlbmQgb2YgdHJhY2UgbGluZSBpZ25vcmVkCkNvZGU6IDhjNTAw MDA4ICBhYzQwMDAwOCAgMDIwMDIwMjEgPDhjODIwMDc0PiAxMDUxMDAwOSAgOGUxMDAwMDAgIGMw ODMwMDc0ICAwMDcxMTAyMyAgZTA4MjAwNzQKCgo+PlJBOyAgMDAwMDAwMDA4MDI0YjA5NCA8c2ti X3JlbGVhc2VfZGF0YStiMC9iYz4KPj4kOTsgMDAwMDAwMDA4MDJkYTFhMCA8bWVtc2V0X3BhcnRp YWwrMjQvNmM+Cj4+JDIxOyAwMDAwMDAwMDgwMjRiMTc4IDxfX2tmcmVlX3NrYisxMC8xMzA+Cj4+ JDMxOyAwMDAwMDAwMDgwMjRiMDk0IDxza2JfcmVsZWFzZV9kYXRhK2IwL2JjPgoKPj5QQzsgIDAw MDAwMDAwODAyNGFmNmMgPHNrYl9kcm9wX2ZyYWdsaXN0KzM0Lzc0PiAgIDw9PT09PQoKVHJhY2U7 IDAwMDAwMDAwODAyNWE0ODQgPG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDA4MDI0 YjA5NCA8c2tiX3JlbGVhc2VfZGF0YStiMC9iYz4KVHJhY2U7IDAwMDAwMDAwODAyNmE5MGMgPGlw X2ZpbmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwODAyNGIwYzQgPGtmcmVlX3Nr Ym1lbSsyNC9jOD4KVHJhY2U7IDAwMDAwMDAwODAyZGEwZTAgPG1lbXNldCswLzFjPgpUcmFjZTsg MDAwMDAwMDA4MDI0YjI5OCA8c2tiX2Nsb25lKzAvMjUwPgpUcmFjZTsgMDAwMDAwMDBjMDE3MWY1 OCA8RU5EX09GX0NPREUrM2ZkZGY3NTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNGFlMzggPGFs bG9jX3NrYisxNjAvMjYwPgpUcmFjZTsgMDAwMDAwMDA4MDJkOWQ4MCA8bWVtY3B5KzAvND4KVHJh Y2U7IDAwMDAwMDAwYzAxNzFlMTAgPEVORF9PRl9DT0RFKzNmZGRmNjEwLz8/Pz8+ClRyYWNlOyAw MDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAw MGMwMTcyNDE0IDxFTkRfT0ZfQ09ERSszZmRkZmMxNC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDBjMDE3 NDBlOCA8RU5EX09GX0NPREUrM2ZkZTE4ZTgvPz8/Pz4KVHJhY2U7IDAwMDAwMDAwODAyNWE0ODQg PG5mX2l0ZXJhdGUrOTQvMTE0PgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291 dHB1dDIrMTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI2YTkwYyA8aXBfZmluaXNoX291dHB1dDIr MTAvMTUwPgpUcmFjZTsgMDAwMDAwMDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRy YWNlOyAwMDAwMDAwMDgwMmRhMGUwIDxtZW1zZXQrMC8xYz4KVHJhY2U7IDAwMDAwMDAwODAyNmE5 MGMgPGlwX2ZpbmlzaF9vdXRwdXQyKzEwLzE1MD4KVHJhY2U7IDAwMDAwMDAwYzAxNzUxZGMgPEVO RF9PRl9DT0RFKzNmZGUyOWRjLz8/Pz8+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOGQ0IDxpcF9maW5p c2hfb3V0cHV0KzFhMC8xYTQ+ClRyYWNlOyAwMDAwMDAwMDgwMjZhOTBjIDxpcF9maW5pc2hfb3V0 cHV0MisxMC8xNTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhMzBjIDxpcF9mcmFnbWVudCszYzgvNTAw PgpUcmFjZTsgMDAwMDAwMDA4MDI2YTE4NCA8aXBfZnJhZ21lbnQrMjQwLzUwMD4KVHJhY2U7IDAw MDAwMDAwODAyNjcxMzAgPGlwX2ZvcndhcmRfZmluaXNoKzEwL2EwPgpUcmFjZTsgMDAwMDAwMDA4 MDI2NzFiMCA8aXBfZm9yd2FyZF9maW5pc2grOTAvYTA+ClRyYWNlOyAwMDAwMDAwMDgwMjZhNzQ0 IDxpcF9maW5pc2hfb3V0cHV0KzEwLzFhND4KVHJhY2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hv b2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAwMDA4MDI2NzEzMCA8aXBfZm9yd2FyZF9maW5p c2grMTAvYTA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MDZjIDxfX2dudV9jb21waWxlZF9jKzI2Yy8z MjA+ClRyYWNlOyAwMDAwMDAwMDgwMjY3MTMwIDxpcF9mb3J3YXJkX2ZpbmlzaCsxMC9hMD4KVHJh Y2U7IDAwMDAwMDAwODAyNjU3ZjggPGlwX3Jjdl9maW5pc2grMTAvMmE4PgpUcmFjZTsgMDAwMDAw MDA4MDI2NWEyMCA8aXBfcmN2X2ZpbmlzaCsyMzgvMmE4PgpUcmFjZTsgMDAwMDAwMDA4MDI1YTQ4 NCA8bmZfaXRlcmF0ZSs5NC8xMTQ+ClRyYWNlOyAwMDAwMDAwMGMwMWNlMmE4IDxFTkRfT0ZfQ09E RSszZmUzYmFhOC8/Pz8/PgpUcmFjZTsgMDAwMDAwMDA4MDI2NTdmOCA8aXBfcmN2X2ZpbmlzaCsx MC8yYTg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KVHJh Y2U7IDAwMDAwMDAwODAyNWE5OGMgPG5mX2hvb2tfc2xvdysxNmMvMWY4PgpUcmFjZTsgMDAwMDAw MDA4MDI1YTk0OCA8bmZfaG9va19zbG93KzEyOC8xZjg+ClRyYWNlOyAwMDAwMDAwMDgwMjY1N2Y4 IDxpcF9yY3ZfZmluaXNoKzEwLzJhOD4KCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjYwIDxza2JfZHJv cF9mcmFnbGlzdCsyOC83ND4KMDAwMDAwMDAgPF9QQz46CkNvZGU7ICAwMDAwMDAwMDgwMjRhZjYw IDxza2JfZHJvcF9mcmFnbGlzdCsyOC83ND4KICAgMDogICA4YzUwMDAwOCAgbHcgICAgICBzMCw4 KHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2NCA8c2tiX2Ryb3BfZnJhZ2xpc3QrMmMvNzQ+CiAg IDQ6ICAgYWM0MDAwMDggIHN3ICAgICAgemVybyw4KHYwKQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY2 OCA8c2tiX2Ryb3BfZnJhZ2xpc3QrMzAvNzQ+CiAgIDg6ICAgMDIwMDIwMjEgIG1vdmUgICAgYTAs czAKQ29kZTsgIDAwMDAwMDAwODAyNGFmNmMgPHNrYl9kcm9wX2ZyYWdsaXN0KzM0Lzc0PiAgIDw9 PT09PQogICBjOiAgIDhjODIwMDc0ICBsdyAgICAgIHYwLDExNihhMCkgICA8PT09PT0KQ29kZTsg IDAwMDAwMDAwODAyNGFmNzAgPHNrYl9kcm9wX2ZyYWdsaXN0KzM4Lzc0PgogIDEwOiAgIDEwNTEw MDA5ICBiZXEgICAgIHYwLHMxLDM4IDxfUEMrMHgzOD4KQ29kZTsgIDAwMDAwMDAwODAyNGFmNzQg PHNrYl9kcm9wX2ZyYWdsaXN0KzNjLzc0PgogIDE0OiAgIDhlMTAwMDAwICBsdyAgICAgIHMwLDAo czApCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjc4IDxza2JfZHJvcF9mcmFnbGlzdCs0MC83ND4KICAx ODogICBjMDgzMDA3NCAgbGwgICAgICB2MSwxMTYoYTApCkNvZGU7ICAwMDAwMDAwMDgwMjRhZjdj IDxza2JfZHJvcF9mcmFnbGlzdCs0NC83ND4KICAxYzogICAwMDcxMTAyMyAgc3VidSAgICB2MCx2 MSxzMQpDb2RlOyAgMDAwMDAwMDA4MDI0YWY4MCA8c2tiX2Ryb3BfZnJhZ2xpc3QrNDgvNzQ+CiAg MjA6ICAgZTA4MjAwNzQgIHNjICAgICAgdjAsMTE2KGEwKQoKS2VybmVsIHBhbmljOiBBaWVlLCBr aWxsaW5nIGludGVycnVwdCBoYW5kbGVyIQoKMSB3YXJuaW5nIGlzc3VlZC4gIFJlc3VsdHMgbWF5 IG5vdCBiZSByZWxpYWJsZS4K ------_=_NextPart_001_01C5669D.E951F95B-- From jaegert@us.ibm.com Wed Jun 1 07:00:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 07:00:54 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51E0bXq012794 for ; Wed, 1 Jun 2005 07:00:44 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j51Dxf89024306 for ; Wed, 1 Jun 2005 09:59:41 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j51DxftR261752 for ; Wed, 1 Jun 2005 09:59:41 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j51DxfQI017299 for ; Wed, 1 Jun 2005 09:59:41 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j51DxfnV017282; Wed, 1 Jun 2005 09:59:41 -0400 In-Reply-To: To: James Morris Cc: chrisw@osdl.org, latten@austin.ibm.com, netdev@oss.sgi.com, sds@tycho.nsa.gov, serue@us.ibm.com MIME-Version: 1.0 Subject: Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Trent Jaeger Message-ID: Date: Wed, 1 Jun 2005 09:59:40 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 06/01/2005 09:59:40, Serialize complete at 06/01/2005 09:59:40 Content-Type: multipart/alternative; boundary="=_alternative 004CDF1985257013_=" X-archive-position: 1943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jaegert@us.ibm.com Precedence: bulk X-list: netdev This is a multipart message in MIME format. --=_alternative 004CDF1985257013_= Content-Type: text/plain; charset="US-ASCII" OK. Thanks for the detailed comments. I will review and get back with comments and mods (probably next week). Regards, Trent. ------------------------------------------------------------ Trent Jaeger IBM T.J. Watson Research Center 19 Skyline Drive, Hawthorne, NY 10532 (914) 784-7225, FAX (914) 784-7225 James Morris 05/31/2005 12:15 AM To: Trent Jaeger/Watson/IBM@IBMUS cc: netdev@oss.sgi.com, , serue@us.ltcfwd.linux.ibm.com, , Subject: Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks On Tue, 17 May 2005, jaegert wrote: Ok, my last review in this iteration. > @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr > x->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime; > x->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime; > } > + > + sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1]; > + if (sec_ctx != NULL) { > + if (security_xfrm_state_alloc(x, sec_ctx)) > + goto out; You should propagate the return value of security_xfrm_state_alloc() here by assigning it to err. > -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o > +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o What about making nethooks.o (or whatever it'll be called) conditionally compiled via CONFIG_SECURITY_NETWORK_XFRM ? (see netif.o) > + * ISSUES: > + * 1. Caching packets, so they are not dropped during negotiation This needs to be done for IPsec in general, not sure what the status is. > + * 2. Emulating a reasonable SO_PEERSEC across machines This may not be too difficult if we limit this to connected TCP sockets. > + * 3. Testing sk_policy setting with context What does this mean? Overall, this looks like a really good approach to the problem. - James -- James Morris --=_alternative 004CDF1985257013_= Content-Type: text/html; charset="US-ASCII"
OK.

Thanks for the detailed comments.  

I will review and get back with comments and mods (probably next week).

Regards,
Trent.
------------------------------------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225


James Morris <jmorris@redhat.com>

05/31/2005 12:15 AM

       
        To:        Trent Jaeger/Watson/IBM@IBMUS
        cc:        netdev@oss.sgi.com, <chrisw@osdl.org>, serue@us.ltcfwd.linux.ibm.com, <latten@austin.ibm.com>, <sds@tycho.nsa.gov>
        Subject:        Re: [PATCH 2/2] Resend: LSM-IPSec Networking Hooks



On Tue, 17 May 2005, jaegert wrote:
Ok, my last review in this iteration.
> @@ -984,6 +1029,13 @@ static struct xfrm_state * pfkey_msg2xfr
>                x->lft.soft_add_expires_seconds = lifetime->sadb_lifetime_addtime;
>                x->lft.soft_use_expires_seconds = lifetime->sadb_lifetime_usetime;
>        }
> +
> +       sec_ctx = (struct sadb_x_sec_ctx *) ext_hdrs[SADB_X_EXT_SEC_CTX-1];
> +       if (sec_ctx != NULL) {
> +               if (security_xfrm_state_alloc(x, sec_ctx))
> +                       goto out;
You should propagate the return value of security_xfrm_state_alloc() here
by assigning it to err.
> -selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o
> +selinux-y := avc.o hooks.o selinuxfs.o netlink.o nlmsgtab.o nethooks.o
What about making nethooks.o (or whatever it'll be called) conditionally
compiled via CONFIG_SECURITY_NETWORK_XFRM ? (see netif.o)

> + * ISSUES:
> + *   1. Caching packets, so they are not dropped during negotiation
This needs to be done for IPsec in general, not sure what the status is.
> + *   2. Emulating a reasonable SO_PEERSEC across machines
This may not be too difficult if we limit this to connected TCP sockets.
> + *   3. Testing sk_policy setting with context
What does this mean?

Overall, this looks like a really good approach to the problem.

- James
--
James Morris
<jmorris@redhat.com>


--=_alternative 004CDF1985257013_=-- From kernel@linuxace.com Wed Jun 1 10:01:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 10:01:59 -0700 (PDT) Received: from linuxace.com (adsl-67-120-171-161.dsl.lsan03.pacbell.net [67.120.171.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j51H1sXq026236 for ; Wed, 1 Jun 2005 10:01:54 -0700 Received: (qmail 20132 invoked by uid 0); 1 Jun 2005 17:00:58 -0000 Date: Wed, 1 Jun 2005 10:00:58 -0700 From: Phil Oester To: Herbert Xu Cc: netdev@oss.sgi.com, akpm@osdl.org Subject: Re: 2.6.12-rcx networking oops Message-ID: <20050601170058.GA20112@linuxace.com> References: <20050531224012.GA16789@linuxace.com> <20050601054955.GA2625@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601054955.GA2625@gondor.apana.org.au> User-Agent: Mutt/1.4.1i X-archive-position: 1944 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@linuxace.com Precedence: bulk X-list: netdev On Wed, Jun 01, 2005 at 03:49:55PM +1000, Herbert Xu wrote: > This looks like stack overflow. %esi is meant to be "res" which is > a local variable. As you can see, it's pointing below %esp and > threadinfo. Ok, so I enabled DEBUG_STACKOVERFLOW in addition to CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC, and got the below today...so maybe it is a slab issue? 0xc0238cdd is in dst_alloc (net/core/dst.c:124). 119 if (ops->gc && atomic_read(&ops->entries) > ops->gc_thresh) { 120 if (ops->gc()) 121 return NULL; 122 } 123 dst = kmem_cache_alloc(ops->kmem_cachep, SLAB_ATOMIC); 0xc013912b is at mm/slab.c:3077. 3072 size = kmem_cache_size(c); 3073 local_irq_restore(flags); 3074 } 3075 3076 return size; 3077 } Phil invalid operand: 0000 [#1] SMP DEBUG_PAGEALLOC CPU: 1 EIP: 0060:[] Not tainted VLI EFLAGS: 00016292 (2.6.12-rc5-git5) EIP is at ksize+0x7b/0x100 eax: c0238cdd ebx: f7ba9c20 ecx: f7babf78 edx: dcc59000 esi: 00000020 edi: 0000e3ba ebp: c0338d98 esp: c0338d88 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0338000 task=c1989b00) Stack: 00000000 04000000 c02d1a00 ffffff97 c0338db0 c0238cdd c0338e58 04000000 00000000 ffffff97 c0338eb4 c0245cb7 00000002 f7b01000 c0338dec c0338df0 f7318ef8 00000000 00000000 00000001 f72dbef8 0000a704 103c243b f27ceec0 Call Trace: [] show_stack+0x7a/0x90 [] show_registers+0x14d/0x1b0 [] die+0xf9/0x180 [] do_trap+0xa0/0xb0 [] do_invalid_op+0xa9/0xc0 [] error_code+0x4f/0x54 [] dst_alloc+0x2d/0xa0 [] ip_route_input_slow+0x4a7/0x840 [] ip_route_input+0x9a/0x160 [] ip_rcv+0x3b0/0x4d0 [] netif_receive_skb+0x13a/0x1a0 [] e1000_clean_rx_irq+0x180/0x4d0 [] e1000_clean+0x40/0xe0 [] net_rx_action+0x90/0x130 [] __do_softirq+0xd4/0xf0 [] do_softirq+0x52/0x70 ======================= [] irq_exit+0x3a/0x40 [] do_IRQ+0x68/0xa0 [] common_interrupt+0x1a/0x20 [] cpu_idle+0x7b/0x80 [] start_secondary+0x73/0x90 [<00000000>] stext+0x3feffd6c/0xc [] 0xc198afb4 Code: 8d 05 0c e2 34 c0 e8 e9 25 15 00 e9 96 dd ff ff 8d 05 0c e2 34 c0 e8 a9 25 15 00 e9 00 e2 ff ff 8d 05 0c e2 34 c0 e8 c9 25 15 00 23 e2 ff ff 8d 05 0c e2 34 c0 e8 89 25 15 00 e9 84 e2 ff ff <0>Kernel panic - not syncing: Fatal exception in interrupt From mmporter@cox.net Wed Jun 1 11:26:34 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 11:26:39 -0700 (PDT) Received: from fed1rmmtao09.cox.net (fed1rmmtao09.cox.net [68.230.241.30]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51IQXXq032754 for ; Wed, 1 Jun 2005 11:26:34 -0700 Received: from liberty.homelinux.org ([68.2.41.86]) by fed1rmmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050601182536.OPJC7275.fed1rmmtao09.cox.net@liberty.homelinux.org>; Wed, 1 Jun 2005 14:25:36 -0400 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA16886; Wed, 1 Jun 2005 11:25:34 -0700 Date: Wed, 1 Jun 2005 11:25:34 -0700 From: Matt Porter To: torvalds@osdl.org, akpm@osdl.org, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org, netdev@oss.sgi.com Subject: [PATCH][3/3] RapidIO support: net driver over messaging Message-ID: <20050601112534.C16559@cox.net> References: <20050601110836.A16559@cox.net> <20050601111516.B16559@cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050601111516.B16559@cox.net>; from mporter@kernel.crashing.org on Wed, Jun 01, 2005 at 11:15:17AM -0700 X-archive-position: 1945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev Adds an "Ethernet" driver which sends Ethernet packets over the standard RapidIO messaging. This depends on the core RIO patch for mailbox/doorbell access. Signed-off-by: Matt Porter Index: drivers/net/Kconfig =================================================================== --- f0bf7810dbe8c4073832d6c3785364084e9523a7/drivers/net/Kconfig (mode:100644) +++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/Kconfig (mode:100644) @@ -2185,6 +2185,20 @@ tristate "iSeries Virtual Ethernet driver support" depends on NETDEVICES && PPC_ISERIES +config RIONET + tristate "RapidIO Ethernet over messaging driver support" + depends on NETDEVICES && RAPIDIO + +config RIONET_TX_SIZE + int "Number of outbound queue entries" + depends on RIONET + default "128" + +config RIONET_RX_SIZE + int "Number of inbound queue entries" + depends on RIONET + default "128" + config FDDI bool "FDDI driver support" depends on NETDEVICES && (PCI || EISA) Index: drivers/net/Makefile =================================================================== --- f0bf7810dbe8c4073832d6c3785364084e9523a7/drivers/net/Makefile (mode:100644) +++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/Makefile (mode:100644) @@ -58,6 +58,7 @@ obj-$(CONFIG_VIA_RHINE) += via-rhine.o obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o +obj-$(CONFIG_RIONET) += rionet.o # # end link order section Index: drivers/net/rionet.c =================================================================== --- /dev/null (tree:f0bf7810dbe8c4073832d6c3785364084e9523a7) +++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/rionet.c (mode:100644) @@ -0,0 +1,622 @@ +/* + * rionet - Ethernet driver over RapidIO messaging services + * + * Copyright 2005 MontaVista Software, Inc. + * Matt Porter + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#define DRV_NAME "rionet" +#define DRV_VERSION "0.1" +#define DRV_AUTHOR "Matt Porter " +#define DRV_DESC "Ethernet over RapidIO" + +MODULE_AUTHOR(DRV_AUTHOR); +MODULE_DESCRIPTION(DRV_DESC); +MODULE_LICENSE("GPL"); + +#define RIONET_DEFAULT_MSGLEVEL 0 +#define RIONET_DOORBELL_JOIN 0x1000 +#define RIONET_DOORBELL_LEAVE 0x1001 + +#define RIONET_MAILBOX 0 + +#define RIONET_TX_RING_SIZE CONFIG_RIONET_TX_SIZE +#define RIONET_RX_RING_SIZE CONFIG_RIONET_RX_SIZE + +LIST_HEAD(rionet_peers); + +struct rionet_private { + struct rio_mport *mport; + struct sk_buff *rx_skb[RIONET_RX_RING_SIZE]; + struct sk_buff *tx_skb[RIONET_TX_RING_SIZE]; + struct net_device_stats stats; + int rx_slot; + int tx_slot; + int tx_cnt; + int ack_slot; + spinlock_t lock; + u32 msg_enable; +}; + +struct rionet_peer { + struct list_head node; + struct rio_dev *rdev; + struct resource *res; +}; + +static int rionet_check = 0; +static int rionet_capable = 1; +static struct net_device *sndev = NULL; + +/* + * This is a fast lookup table for for translating TX + * Ethernet packets into a destination RIO device. It + * could be made into a hash table to save memory depending + * on system trade-offs. + */ +static struct rio_dev *rionet_active[RIO_MAX_ROUTE_ENTRIES]; + +#define is_rionet_capable(pef, src_ops, dst_ops) \ + ((pef & RIO_PEF_INB_MBOX) && \ + (pef & RIO_PEF_INB_DOORBELL) && \ + (src_ops & RIO_SRC_OPS_DOORBELL) && \ + (dst_ops & RIO_DST_OPS_DOORBELL)) +#define dev_rionet_capable(dev) \ + is_rionet_capable(dev->pef, dev->src_ops, dev->dst_ops) + +#define RIONET_MAC_MATCH(x) (*(u32 *)x == 0x00010001) +#define RIONET_GET_DESTID(x) (*(u16 *)(x + 4)) + +static struct net_device_stats *rionet_stats(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + return &rnet->stats; +} + +static int rionet_rx_clean(struct net_device *ndev) +{ + int i; + int error = 0; + struct rionet_private *rnet = ndev->priv; + void *data; + + i = rnet->rx_slot; + + do { + if (!rnet->rx_skb[i]) { + rnet->stats.rx_dropped++; + continue; + } + + if (!(data = rio_get_inb_message(rnet->mport, RIONET_MAILBOX))) + break; + + rnet->rx_skb[i]->data = data; + skb_put(rnet->rx_skb[i], RIO_MAX_MSG_SIZE); + rnet->rx_skb[i]->dev = sndev; + rnet->rx_skb[i]->protocol = + eth_type_trans(rnet->rx_skb[i], sndev); + error = netif_rx(rnet->rx_skb[i]); + + if (error == NET_RX_DROP) { + rnet->stats.rx_dropped++; + } else if (error == NET_RX_BAD) { + if (netif_msg_rx_err(rnet)) + printk(KERN_WARNING "%s: bad rx packet\n", + DRV_NAME); + rnet->stats.rx_errors++; + } else { + rnet->stats.rx_packets++; + rnet->stats.rx_bytes += RIO_MAX_MSG_SIZE; + } + + } while ((i = (i + 1) % RIONET_RX_RING_SIZE) != rnet->rx_slot); + + return i; +} + +static void rionet_rx_fill(struct net_device *ndev, int end) +{ + int i; + struct rionet_private *rnet = ndev->priv; + + i = rnet->rx_slot; + do { + rnet->rx_skb[i] = dev_alloc_skb(RIO_MAX_MSG_SIZE); + + if (!rnet->rx_skb[i]) + break; + + rio_add_inb_buffer(rnet->mport, RIONET_MAILBOX, + rnet->rx_skb[i]->data); + } while ((i = (i + 1) % RIONET_RX_RING_SIZE) != end); + + rnet->rx_slot = i; +} + +static int rionet_queue_tx_msg(struct sk_buff *skb, struct net_device *ndev, + struct rio_dev *rdev) +{ + struct rionet_private *rnet = ndev->priv; + + rio_add_outb_message(rnet->mport, rdev, 0, skb->data, skb->len); + rnet->tx_skb[rnet->tx_slot] = skb; + + rnet->stats.tx_packets++; + rnet->stats.tx_bytes += skb->len; + + if (++rnet->tx_cnt == RIONET_TX_RING_SIZE) + netif_stop_queue(ndev); + + if (++rnet->tx_slot == RIONET_TX_RING_SIZE) + rnet->tx_slot = 0; + + if (netif_msg_tx_queued(rnet)) + printk(KERN_INFO "%s: queued skb %8.8x len %8.8x\n", DRV_NAME, + (u32) skb, skb->len); + + return 0; +} + +static int rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev) +{ + int i; + struct rionet_private *rnet = ndev->priv; + struct ethhdr *eth = (struct ethhdr *)skb->data; + u16 destid; + + spin_lock_irq(&rnet->lock); + + if ((rnet->tx_cnt + 1) > RIONET_TX_RING_SIZE) { + netif_stop_queue(ndev); + spin_unlock_irq(&rnet->lock); + return -EBUSY; + } + + if (eth->h_dest[0] & 0x01) { + /* + * XXX Need to delay queuing if ring max is reached, + * flush additional packets in tx_event() before + * awakening the queue. We can easily exceed ring + * size with a large number of nodes or even a + * small number where the ring is relatively full + * on entrance to hard_start_xmit. + */ + for (i = 0; i < RIO_MAX_ROUTE_ENTRIES; i++) + if (rionet_active[i]) + rionet_queue_tx_msg(skb, ndev, + rionet_active[i]); + } else if (RIONET_MAC_MATCH(eth->h_dest)) { + destid = RIONET_GET_DESTID(eth->h_dest); + if (rionet_active[destid]) + rionet_queue_tx_msg(skb, ndev, rionet_active[destid]); + } + + spin_unlock_irq(&rnet->lock); + + return 0; +} + +static int rionet_set_mac_address(struct net_device *ndev, void *p) +{ + struct sockaddr *addr = p; + + if (!is_valid_ether_addr(addr->sa_data)) + return -EADDRNOTAVAIL; + + memcpy(ndev->dev_addr, addr->sa_data, ndev->addr_len); + + return 0; +} + +static int rionet_change_mtu(struct net_device *ndev, int new_mtu) +{ + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_drv(rnet)) + printk(KERN_WARNING + "%s: rionet_change_mtu(): not implemented\n", DRV_NAME); + + return 0; +} + +static void rionet_set_multicast_list(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_drv(rnet)) + printk(KERN_WARNING + "%s: rionet_set_multicast_list(): not implemented\n", + DRV_NAME); +} + +static void rionet_dbell_event(struct rio_mport *mport, u16 sid, u16 tid, + u16 info) +{ + struct net_device *ndev = sndev; + struct rionet_private *rnet = ndev->priv; + struct rionet_peer *peer; + + if (netif_msg_intr(rnet)) + printk(KERN_INFO "%s: doorbell sid %4.4x tid %4.4x info %4.4x", + DRV_NAME, sid, tid, info); + if (info == RIONET_DOORBELL_JOIN) { + if (!rionet_active[sid]) { + list_for_each_entry(peer, &rionet_peers, node) { + if (peer->rdev->destid == sid) + rionet_active[sid] = peer->rdev; + } + rio_mport_send_doorbell(mport, sid, + RIONET_DOORBELL_JOIN); + } + } else if (info == RIONET_DOORBELL_LEAVE) { + rionet_active[sid] = NULL; + } else { + if (netif_msg_intr(rnet)) + printk(KERN_WARNING "%s: unhandled doorbell\n", + DRV_NAME); + } +} + +static void rionet_inb_msg_event(struct rio_mport *mport, int mbox, int slot) +{ + int n; + struct net_device *ndev = sndev; + struct rionet_private *rnet = (struct rionet_private *)ndev->priv; + + if (netif_msg_intr(rnet)) + printk(KERN_INFO "%s: inbound message event, mbox %d slot %d\n", + DRV_NAME, mbox, slot); + + spin_lock(&rnet->lock); + if ((n = rionet_rx_clean(ndev)) != rnet->rx_slot) + rionet_rx_fill(ndev, n); + spin_unlock(&rnet->lock); +} + +static void rionet_outb_msg_event(struct rio_mport *mport, int mbox, int slot) +{ + struct net_device *ndev = sndev; + struct rionet_private *rnet = ndev->priv; + + spin_lock(&rnet->lock); + + if (netif_msg_intr(rnet)) + printk(KERN_INFO + "%s: outbound message event, mbox %d slot %d\n", + DRV_NAME, mbox, slot); + + while (rnet->tx_cnt && (rnet->ack_slot != slot)) { + /* dma unmap single */ + dev_kfree_skb_irq(rnet->tx_skb[rnet->ack_slot]); + rnet->tx_skb[rnet->ack_slot] = NULL; + if (++rnet->ack_slot == RIONET_TX_RING_SIZE) + rnet->ack_slot = 0; + rnet->tx_cnt--; + } + + if (rnet->tx_cnt < RIONET_TX_RING_SIZE) + netif_wake_queue(ndev); + + spin_unlock(&rnet->lock); +} + +static int rionet_open(struct net_device *ndev) +{ + int i, rc = 0; + struct rionet_peer *peer, *tmp; + u32 pwdcsr; + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_ifup(rnet)) + printk(KERN_INFO "%s: open\n", DRV_NAME); + + if ((rc = rio_request_inb_dbell(rnet->mport, + RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE, + rionet_dbell_event)) < 0) + goto out; + + if ((rc = rio_request_inb_mbox(rnet->mport, + RIONET_MAILBOX, + RIONET_RX_RING_SIZE, + rionet_inb_msg_event)) < 0) + goto out; + + if ((rc = rio_request_outb_mbox(rnet->mport, + RIONET_MAILBOX, + RIONET_TX_RING_SIZE, + rionet_outb_msg_event)) < 0) + goto out; + + /* Initialize inbound message ring */ + for (i = 0; i < RIONET_RX_RING_SIZE; i++) + rnet->rx_skb[i] = NULL; + rnet->rx_slot = 0; + rionet_rx_fill(ndev, 0); + + rnet->tx_slot = 0; + rnet->tx_cnt = 0; + rnet->ack_slot = 0; + + spin_lock_init(&rnet->lock); + + rnet->msg_enable = RIONET_DEFAULT_MSGLEVEL; + + netif_carrier_on(ndev); + netif_start_queue(ndev); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + if (!(peer->res = rio_request_outb_dbell(peer->rdev, + RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE))) + { + printk(KERN_ERR "%s: error requesting doorbells\n", + DRV_NAME); + continue; + } + + /* + * If device has initialized inbound doorbells, + * send a join message + */ + rio_read_config_32(peer->rdev, RIO_WRITE_PORT_CSR, &pwdcsr); + if (pwdcsr & RIO_DOORBELL_AVAIL) + rio_send_doorbell(peer->rdev, RIONET_DOORBELL_JOIN); + } + + out: + return rc; +} + +static int rionet_close(struct net_device *ndev) +{ + struct rionet_private *rnet = (struct rionet_private *)ndev->priv; + struct rionet_peer *peer, *tmp; + int i; + + if (netif_msg_ifup(rnet)) + printk(KERN_INFO "%s: close\n", DRV_NAME); + + netif_stop_queue(ndev); + netif_carrier_off(ndev); + + for (i = 0; i < RIONET_RX_RING_SIZE; i++) + if (rnet->rx_skb[i]) + kfree_skb(rnet->rx_skb[i]); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + if (rionet_active[peer->rdev->destid]) { + rio_send_doorbell(peer->rdev, RIONET_DOORBELL_LEAVE); + rionet_active[peer->rdev->destid] = NULL; + } + rio_release_outb_dbell(peer->rdev, peer->res); + } + + rio_release_inb_dbell(rnet->mport, RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE); + rio_release_inb_mbox(rnet->mport, RIONET_MAILBOX); + rio_release_outb_mbox(rnet->mport, RIONET_MAILBOX); + + return 0; +} + +static void rionet_remove(struct rio_dev *rdev) +{ + struct net_device *ndev = NULL; + struct rionet_peer *peer, *tmp; + + unregister_netdev(ndev); + kfree(ndev); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + list_del(&peer->node); + kfree(peer); + } +} + +static int rionet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) +{ + return -EOPNOTSUPP; +} + +static void rionet_get_drvinfo(struct net_device *ndev, + struct ethtool_drvinfo *info) +{ + struct rionet_private *rnet = ndev->priv; + + strcpy(info->driver, DRV_NAME); + strcpy(info->version, DRV_VERSION); + strcpy(info->fw_version, "n/a"); + sprintf(info->bus_info, "RIO master port %d", rnet->mport->id); +} + +static u32 rionet_get_msglevel(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + + return rnet->msg_enable; +} + +static void rionet_set_msglevel(struct net_device *ndev, u32 value) +{ + struct rionet_private *rnet = ndev->priv; + + rnet->msg_enable = value; +} + +static u32 rionet_get_link(struct net_device *ndev) +{ + return netif_carrier_ok(ndev); +} + +static struct ethtool_ops rionet_ethtool_ops = { + .get_drvinfo = rionet_get_drvinfo, + .get_msglevel = rionet_get_msglevel, + .set_msglevel = rionet_set_msglevel, + .get_link = rionet_get_link, +}; + +static int rionet_setup_netdev(struct rio_mport *mport) +{ + int rc = 0; + struct net_device *ndev = NULL; + struct rionet_private *rnet; + u16 device_id; + + /* Allocate our net_device structure */ + ndev = alloc_etherdev(sizeof(struct rionet_private)); + if (ndev == NULL) { + printk(KERN_INFO "%s: could not allocate ethernet device.\n", + DRV_NAME); + rc = -ENOMEM; + goto out; + } + + /* + * XXX hack, store point a static at ndev so we can get it... + * Perhaps need an array of these that the handler can + * index via the mbox number. + */ + sndev = ndev; + + /* Set up private area */ + rnet = (struct rionet_private *)ndev->priv; + rnet->mport = mport; + + /* Set the default MAC address */ + device_id = rio_local_get_device_id(mport); + ndev->dev_addr[0] = 0x00; + ndev->dev_addr[1] = 0x01; + ndev->dev_addr[2] = 0x00; + ndev->dev_addr[3] = 0x01; + ndev->dev_addr[4] = device_id >> 8; + ndev->dev_addr[5] = device_id & 0xff; + + /* Fill in the driver function table */ + ndev->open = &rionet_open; + ndev->hard_start_xmit = &rionet_start_xmit; + ndev->stop = &rionet_close; + ndev->get_stats = &rionet_stats; + ndev->change_mtu = &rionet_change_mtu; + ndev->set_mac_address = &rionet_set_mac_address; + ndev->set_multicast_list = &rionet_set_multicast_list; + ndev->do_ioctl = &rionet_ioctl; + SET_ETHTOOL_OPS(ndev, &rionet_ethtool_ops); + + ndev->mtu = RIO_MAX_MSG_SIZE - 14; + + SET_MODULE_OWNER(ndev); + + rc = register_netdev(ndev); + if (rc != 0) + goto out; + + printk("%s: %s %s Version %s, MAC %02x:%02x:%02x:%02x:%02x:%02x\n", + ndev->name, + DRV_NAME, + DRV_DESC, + DRV_VERSION, + ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2], + ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]); + + out: + return rc; +} + +/* + * XXX Make multi-net safe + */ +static int rionet_probe(struct rio_dev *rdev, const struct rio_device_id *id) +{ + int rc = -ENODEV; + u32 lpef, lsrc_ops, ldst_ops; + struct rionet_peer *peer; + + /* If local device is not rionet capable, give up quickly */ + if (!rionet_capable) + goto out; + + /* + * First time through, make sure local device is rionet + * capable, setup netdev, and set flags so this is skipped + * on later probes + */ + if (!rionet_check) { + rio_local_read_config_32(rdev->net->hport, RIO_PEF_CAR, &lpef); + rio_local_read_config_32(rdev->net->hport, RIO_SRC_OPS_CAR, + &lsrc_ops); + rio_local_read_config_32(rdev->net->hport, RIO_DST_OPS_CAR, + &ldst_ops); + if (!is_rionet_capable(lpef, lsrc_ops, ldst_ops)) { + printk(KERN_ERR + "%s: local device is not network capable\n", + DRV_NAME); + rionet_check = 1; + rionet_capable = 0; + goto out; + } + + rc = rionet_setup_netdev(rdev->net->hport); + rionet_check = 1; + } + + /* + * If the remote device has mailbox/doorbell capabilities, + * add it to the peer list. + */ + if (dev_rionet_capable(rdev)) { + if (!(peer = kmalloc(sizeof(struct rionet_peer), GFP_KERNEL))) { + rc = -ENOMEM; + goto out; + } + peer->rdev = rdev; + list_add_tail(&peer->node, &rionet_peers); + } + + out: + return rc; +} + +static struct rio_device_id rionet_id_table[] = { + {RIO_DEVICE(RIO_ANY_ID, RIO_ANY_ID)} +}; + +static struct rio_driver rionet_driver = { + .name = "rionet", + .id_table = rionet_id_table, + .probe = rionet_probe, + .remove = rionet_remove, +}; + +static int __init rionet_init(void) +{ + return rio_register_driver(&rionet_driver); +} + +static void __exit rionet_exit(void) +{ + rio_unregister_driver(&rionet_driver); +} + +module_init(rionet_init); +module_exit(rionet_exit); From davem@davemloft.net Wed Jun 1 11:56:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 11:56:30 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51IuMXq001813 for ; Wed, 1 Jun 2005 11:56:28 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdYMW-0003Ku-N6; Wed, 01 Jun 2005 11:54:44 -0700 Date: Wed, 01 Jun 2005 11:54:44 -0700 (PDT) Message-Id: <20050601.115444.68157121.davem@davemloft.net> To: raghunathan.venkatesan@wipro.com Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, linux@der-keiler.de Subject: Re: Unable to handle kernel paging request at virtual address 04000460 From: "David S. Miller" In-Reply-To: <438662DA48DCAA41B1DF648BD4BD76C0E45DF1@CHN-SNR-MBX01.wipro.com> References: <438662DA48DCAA41B1DF648BD4BD76C0E45DF1@CHN-SNR-MBX01.wipro.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Please don't ask the community to debug your custom kernel with private VPN driver modules installed. From afleming@freescale.com Wed Jun 1 13:46:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 13:46:40 -0700 (PDT) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51KkZXq010355 for ; Wed, 1 Jun 2005 13:46:36 -0700 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j51KouYg020960; Wed, 1 Jun 2005 13:50:56 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j51KmgBH016530; Wed, 1 Jun 2005 15:48:42 -0500 (CDT) In-Reply-To: <20050531105939.7486e071@dxpl.pdx.osdl.net> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> Cc: Netdev , Embedded PPC Linux list , Kumar Gala Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 1 Jun 2005 15:45:26 -0500 To: Stephen Hemminger X-Mailer: Apple Mail (2.730) X-archive-position: 1947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev On May 31, 2005, at 12:59, Stephen Hemminger wrote: > Here are some patches: > * allow phy's to be modules > * use driver owner for ref count > * make local functions static where ever possible I agree with all these. > * get rid of bus read may sleep implication in comment. > since you are holding phy spin lock it better not!! But not this one. The phy_read and phy_write functions are reading from and writing to a bus. It is a reasonable implementation to have the operation block in the bus driver, and be awoken when an interrupt signals the operation is done. All of the phydev spinlocks have been arranged so as to prevent the lock being taken during interrupt time. Unless I've misunderstood spinlocks (it wouldn't be the first time), as long as the lock is never taken in interrupt time, it should be ok to hold the lock, and wait for an interrupt before clearing the lock. Andy Fleming From gwingerde@home.nl Wed Jun 1 13:58:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 13:58:33 -0700 (PDT) Received: from smtpq3.home.nl (smtpq3.home.nl [213.51.128.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51KwRXq011274 for ; Wed, 1 Jun 2005 13:58:29 -0700 Received: from [213.51.128.134] (port=47200 helo=smtp3.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1DdaHH-0007SM-4Z; Wed, 01 Jun 2005 22:57:27 +0200 Received: from cc10088-a.ensch1.ov.home.nl ([217.123.128.105]:58103 helo=[192.168.14.1]) by smtp3.home.nl with esmtp (Exim 4.30) id 1DdaHF-0000hZ-Q1; Wed, 01 Jun 2005 22:57:25 +0200 Message-ID: <429E1FAB.6080503@home.nl> Date: Wed, 01 Jun 2005 22:50:51 +0200 From: Gertjan van Wingerde User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, jgarzik@pobox.com Subject: [PATCH] ieee80211: Update generic definitions to latest specs. Content-Type: multipart/mixed; boundary="------------020800010603020503020809" X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean X-archive-position: 1948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------020800010603020503020809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Attached patch updates the definitions of the generic ieee80211 stack to the latest versions of the published 802.11x specification suite. Please review and apply. Signed-off-by: Gertjan van Wingerde --------------020800010603020503020809 Content-Type: text/plain; name="ieee80211.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ieee80211.diff" Index: include/net/ieee80211.h =================================================================== --- 4b4ba76aa81b3627142787262fd2f8049dd3662d/include/net/ieee80211.h (mode:100644) +++ uncommitted/include/net/ieee80211.h (mode:100644) @@ -103,7 +103,7 @@ #define MAX_FRAG_THRESHOLD 2346U /* Frame control field constants */ -#define IEEE80211_FCTL_VERS 0x0002 +#define IEEE80211_FCTL_VERS 0x0003 #define IEEE80211_FCTL_FTYPE 0x000c #define IEEE80211_FCTL_STYPE 0x00f0 #define IEEE80211_FCTL_TODS 0x0100 @@ -111,8 +111,8 @@ #define IEEE80211_FCTL_MOREFRAGS 0x0400 #define IEEE80211_FCTL_RETRY 0x0800 #define IEEE80211_FCTL_PM 0x1000 -#define IEEE80211_FCTL_MOREDATA 0x2000 -#define IEEE80211_FCTL_WEP 0x4000 +#define IEEE80211_FCTL_MOREDATA 0x2000 +#define IEEE80211_FCTL_PROTECTEDFRAME 0x4000 #define IEEE80211_FCTL_ORDER 0x8000 #define IEEE80211_FTYPE_MGMT 0x0000 @@ -131,6 +131,7 @@ #define IEEE80211_STYPE_DISASSOC 0x00A0 #define IEEE80211_STYPE_AUTH 0x00B0 #define IEEE80211_STYPE_DEAUTH 0x00C0 +#define IEEE80211_STYPE_ACTION 0x00D0 /* control */ #define IEEE80211_STYPE_PSPOLL 0x00A0 @@ -251,6 +252,7 @@ #define SNAP_SIZE sizeof(struct ieee80211_snap_hdr) +#define WLAN_FC_GET_VERS(fc) ((fc) & IEEE80211_FCTL_VERS) #define WLAN_FC_GET_TYPE(fc) ((fc) & IEEE80211_FCTL_FTYPE) #define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE) @@ -271,6 +273,9 @@ #define WLAN_CAPABILITY_SHORT_PREAMBLE (1<<5) #define WLAN_CAPABILITY_PBCC (1<<6) #define WLAN_CAPABILITY_CHANNEL_AGILITY (1<<7) +#define WLAN_CAPABILITY_SPECTRUM_MGMT (1<<8) +#define WLAN_CAPABILITY_SHORT_SLOT_TIME (1<<10) +#define WLAN_CAPABILITY_OSSS_OFDM (1<<13) /* Status codes */ #define WLAN_STATUS_SUCCESS 0 @@ -285,9 +290,24 @@ #define WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA 17 #define WLAN_STATUS_ASSOC_DENIED_RATES 18 /* 802.11b */ -#define WLAN_STATUS_ASSOC_DENIED_NOSHORT 19 +#define WLAN_STATUS_ASSOC_DENIED_NOSHORTPREAMBLE 19 #define WLAN_STATUS_ASSOC_DENIED_NOPBCC 20 #define WLAN_STATUS_ASSOC_DENIED_NOAGILITY 21 +/* 802.11h */ +#define WLAN_STATUS_ASSOC_DENIED_SPECTRUM_MGMT_REQUIRED 22 +#define WLAN_STATUS_ASSOC_REJECTED_POWER_CAP_UNACCEPTABLE 23 +#define WLAN_STATUS_ASSOC_REJECTED_SUPP_CHANNELS_UNACCEPTABLE 24 +/* 802.11g */ +#define WLAN_STATUS_ASSOC_DENIED_NOSHORTTIME 25 +#define WLAN_STATUS_ASSOC_DENIED_NODSSSOFDM 26 +/* 802.11i */ +#define WLAN_STATUS_INVALID_IE 40 +#define WLAN_STATUS_INVALID_GROUP_CIPHER 41 +#define WLAN_STATUS_INVALID_PAIRWISE_CIPHER 42 +#define WLAN_STATUS_INVALID_AKMP 43 +#define WLAN_STATUS_UNSUPP_RSN_VERSION 44 +#define WLAN_STATUS_INVALID_RSN_IE_CAP 45 +#define WLAN_STATUS_CIPHER_SUITE_REJECTED 46 /* Reason codes */ #define WLAN_REASON_UNSPECIFIED 1 @@ -299,6 +319,22 @@ #define WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA 7 #define WLAN_REASON_DISASSOC_STA_HAS_LEFT 8 #define WLAN_REASON_STA_REQ_ASSOC_WITHOUT_AUTH 9 +/* 802.11h */ +#define WLAN_REASON_DISASSOC_POWER_CAP_UNACCEPTABLE 10 +#define WLAN_REASON_DISASSOC_SUPP_CHANNELS_UNACCEPTABLE 11 +/* 802.11i */ +#define WLAN_REASON_INVALID_IE 13 +#define WLAN_REASON_MIC_FAILURE 14 +#define WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT 15 +#define WLAN_REASON_GROUP_KEY_HANDSHAKE_TIMEOUT 16 +#define WLAN_REASON_IE_DIFFERENT 17 +#define WLAN_REASON_INVALID_GROUP_CIPHER 18 +#define WLAN_REASON_INVALID_PAIRWISE_CIPHER 19 +#define WLAN_REASON_INVALID_AKMP 20 +#define WLAN_REASON_UNSUPP_RSN_VERSION 21 +#define WLAN_REASON_INVALID_RSN_IE_CAP 22 +#define WLAN_REASON_IEEE8021X_FAILED 23 +#define WLAN_REASON_CIPHER_SUITE_REJECTED 24 #define IEEE80211_STATMASK_SIGNAL (1<<0) @@ -477,17 +513,32 @@ #define BEACON_PROBE_SSID_ID_POSITION 12 /* Management Frame Information Element Types */ -#define MFIE_TYPE_SSID 0 -#define MFIE_TYPE_RATES 1 -#define MFIE_TYPE_FH_SET 2 -#define MFIE_TYPE_DS_SET 3 -#define MFIE_TYPE_CF_SET 4 -#define MFIE_TYPE_TIM 5 -#define MFIE_TYPE_IBSS_SET 6 -#define MFIE_TYPE_CHALLENGE 16 -#define MFIE_TYPE_RSN 48 -#define MFIE_TYPE_RATES_EX 50 -#define MFIE_TYPE_GENERIC 221 +#define MFIE_TYPE_SSID 0 +#define MFIE_TYPE_RATES 1 +#define MFIE_TYPE_FH_SET 2 +#define MFIE_TYPE_DS_SET 3 +#define MFIE_TYPE_CF_SET 4 +#define MFIE_TYPE_TIM 5 +#define MFIE_TYPE_IBSS_SET 6 +#define MFIE_TYPE_COUNTRY 7 +#define MFIE_TYPE_HOP_PARAMS 8 +#define MFIE_TYPE_HOP_TABLE 9 +#define MFIE_TYPE_REQUEST 10 +#define MFIE_TYPE_CHALLENGE 16 +#define MFIE_TYPE_POWER_CONSTRAINT 32 +#define MFIE_TYPE_POWER_CAPABILITY 33 +#define MFIE_TYPE_TPC_REQUEST 34 +#define MFIE_TYPE_TPC_REPORT 35 +#define MFIE_TYPE_SUPP_CHANNELS 36 +#define MFIE_TYPE_CSA 37 +#define MFIE_TYPE_MEASURE_REQUEST 38 +#define MFIE_TYPE_MEASURE_REPORT 39 +#define MFIE_TYPE_QUIET 40 +#define MFIE_TYPE_IBSS_DFS 41 +#define MFIE_TYPE_ERP_INFO 42 +#define MFIE_TYPE_RSN 48 +#define MFIE_TYPE_RATES_EX 50 +#define MFIE_TYPE_GENERIC 221 struct ieee80211_info_element_hdr { u8 id; Index: net/ieee80211/ieee80211_rx.c =================================================================== --- 4b4ba76aa81b3627142787262fd2f8049dd3662d/net/ieee80211/ieee80211_rx.c (mode:100644) +++ uncommitted/net/ieee80211/ieee80211_rx.c (mode:100644) @@ -440,7 +440,7 @@ crypt->ops->decrypt_mpdu == NULL)) crypt = NULL; - if (!crypt && (fc & IEEE80211_FCTL_WEP)) { + if (!crypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME)) { /* This seems to be triggered by some (multicast?) * frames from other than current BSS, so just drop the * frames silently instead of filling system log with @@ -456,7 +456,7 @@ #ifdef NOT_YET if (type != WLAN_FC_TYPE_DATA) { if (type == WLAN_FC_TYPE_MGMT && stype == WLAN_FC_STYPE_AUTH && - fc & IEEE80211_FCTL_WEP && ieee->host_decrypt && + fc & IEEE80211_FCTL_PROTECTEDFRAME && ieee->host_decrypt && (keyidx = hostap_rx_frame_decrypt(ieee, skb, crypt)) < 0) { printk(KERN_DEBUG "%s: failed to decrypt mgmt::auth " @@ -557,7 +557,7 @@ /* skb: hdr + (possibly fragmented, possibly encrypted) payload */ - if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) && (keyidx = ieee80211_rx_frame_decrypt(ieee, skb, crypt)) < 0) goto rx_dropped; @@ -565,7 +565,7 @@ /* skb: hdr + (possibly fragmented) plaintext payload */ // PR: FIXME: hostap has additional conditions in the "if" below: - // ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + // ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) && if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) { int flen; struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr); @@ -621,12 +621,12 @@ /* skb: hdr + (possible reassembled) full MSDU payload; possibly still * encrypted/authenticated */ - if (ieee->host_decrypt && (fc & IEEE80211_FCTL_WEP) && + if (ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTEDFRAME) && ieee80211_rx_frame_decrypt_msdu(ieee, skb, keyidx, crypt)) goto rx_dropped; hdr = (struct ieee80211_hdr *) skb->data; - if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep) { + if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) && !ieee->open_wep) { if (/*ieee->ieee802_1x &&*/ ieee80211_is_eapol_frame(ieee, skb)) { #ifdef CONFIG_IEEE80211_DEBUG @@ -647,7 +647,7 @@ } #ifdef CONFIG_IEEE80211_DEBUG - if (crypt && !(fc & IEEE80211_FCTL_WEP) && + if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) && ieee80211_is_eapol_frame(ieee, skb)) { struct eapol *eap = (struct eapol *)(skb->data + 24); @@ -656,7 +656,7 @@ } #endif - if (crypt && !(fc & IEEE80211_FCTL_WEP) && !ieee->open_wep && + if (crypt && !(fc & IEEE80211_FCTL_PROTECTEDFRAME) && !ieee->open_wep && !ieee80211_is_eapol_frame(ieee, skb)) { IEEE80211_DEBUG_DROP( "dropped unencrypted RX data " Index: net/ieee80211/ieee80211_tx.c =================================================================== --- 4b4ba76aa81b3627142787262fd2f8049dd3662d/net/ieee80211/ieee80211_tx.c (mode:100644) +++ uncommitted/net/ieee80211/ieee80211_tx.c (mode:100644) @@ -314,7 +314,7 @@ if (encrypt) fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA | - IEEE80211_FCTL_WEP; + IEEE80211_FCTL_PROTECTEDFRAME; else fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; Index: drivers/net/wireless/atmel.c =================================================================== --- 4b4ba76aa81b3627142787262fd2f8049dd3662d/drivers/net/wireless/atmel.c (mode:100644) +++ uncommitted/drivers/net/wireless/atmel.c (mode:100644) @@ -867,7 +867,7 @@ header.duration_id = 0; header.seq_ctl = 0; if (priv->wep_is_on) - frame_ctl |= IEEE80211_FCTL_WEP; + frame_ctl |= IEEE80211_FCTL_PROTECTEDFRAME; if (priv->operating_mode == IW_MODE_ADHOC) { memcpy(&header.addr1, skb->data, 6); memcpy(&header.addr2, dev->dev_addr, 6); @@ -1117,7 +1117,7 @@ /* probe for CRC use here if needed once five packets have arrived with the same crc status, we assume we know what's happening and stop probing */ if (priv->probe_crc) { - if (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP)) { + if (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_PROTECTEDFRAME)) { priv->do_rx_crc = probe_crc(priv, rx_packet_loc, msdu_size); } else { priv->do_rx_crc = probe_crc(priv, rx_packet_loc + 24, msdu_size - 24); @@ -1132,7 +1132,7 @@ } /* don't CRC header when WEP in use */ - if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_WEP))) { + if (priv->do_rx_crc && (!priv->wep_is_on || !(frame_ctl & IEEE80211_FCTL_PROTECTEDFRAME))) { crc = crc32_le(0xffffffff, (unsigned char *)&header, 24); } msdu_size -= 24; /* header */ @@ -2677,7 +2677,7 @@ auth.alg = cpu_to_le16(C80211_MGMT_AAN_SHAREDKEY); /* no WEP for authentication frames with TrSeqNo 1 */ if (priv->CurrentAuthentTransactionSeqNum != 1) - header.frame_ctl |= cpu_to_le16(IEEE80211_FCTL_WEP); + header.frame_ctl |= cpu_to_le16(IEEE80211_FCTL_PROTECTEDFRAME); } else { auth.alg = cpu_to_le16(C80211_MGMT_AAN_OPENSYSTEM); } --------------020800010603020503020809-- From shemminger@osdl.org Wed Jun 1 14:20:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 14:20:21 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51LKIXq012488 for ; Wed, 1 Jun 2005 14:20:19 -0700 Received: from [10.8.0.74] (fw.osdl.org [65.172.181.6]) (authenticated bits=0) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j51LJFj9029727 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 1 Jun 2005 14:19:16 -0700 Message-ID: <429E2653.6010101@osdl.org> Date: Wed, 01 Jun 2005 14:19:15 -0700 From: Stephen Hemminger User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Fleming CC: Netdev , Embedded PPC Linux list , Kumar Gala Subject: Re: RFC: PHY Abstraction Layer II References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> In-Reply-To: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Andy Fleming wrote: > > On May 31, 2005, at 12:59, Stephen Hemminger wrote: > >> Here are some patches: >> * allow phy's to be modules >> * use driver owner for ref count >> * make local functions static where ever possible > > > I agree with all these. > >> * get rid of bus read may sleep implication in comment. >> since you are holding phy spin lock it better not!! > > > But not this one. The phy_read and phy_write functions are reading > from and writing to a bus. It is a reasonable implementation to have > the operation block in the bus driver, and be awoken when an > interrupt signals the operation is done. All of the phydev spinlocks > have been arranged so as to prevent the lock being taken during > interrupt time. > > Unless I've misunderstood spinlocks (it wouldn't be the first time), > as long as the lock is never taken in interrupt time, it should be ok > to hold the lock, and wait for an interrupt before clearing the lock. The problem is that sleeping is defined in the linux kernel as meaning waiting on a mutual exclusion primitive (like semaphore) that puts the current thread to sleep. It is not legal to sleep with a spinlock held. In the phy_read code you do: spin_lock_bh(&bus->mdio_lock); retval = bus->read(bus, phydev->addr, regnum); spin_unlock_bh(&bus->mdio_lock); If the bus->read function were to do something like start a request and wait on a semaphore, then you would be sleeping with a spin lock held. So bus->read can not sleep! (as sleep is defined in the linux kernel). From mchan@broadcom.com Wed Jun 1 14:32:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 14:32:36 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51LWXXq013485 for ; Wed, 1 Jun 2005 14:32:33 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 01 Jun 2005 14:31:20 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 1 Jun 2005 14:31:18 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BBO09844; Wed, 1 Jun 2005 14:31:15 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA04566; Wed, 1 Jun 2005 14:31:15 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jun 2005 21:31:14 +0000 Received: from rh4 by nt-irva-0741; 01 Jun 2005 13:33:39 -0700 Subject: Re: Locking model for NAPI drivers From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com In-Reply-To: <20050531.154847.63995530.davem@davemloft.net> References: <20050531.154847.63995530.davem@davemloft.net> Date: Wed, 01 Jun 2005 13:33:39 -0700 Message-ID: <1117658019.4310.58.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E80F6A21VO4407082-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Tue, 2005-05-31 at 15:48 -0700, David S. Miller wrote: > Once we make this transformation, we need some way to synchronize > with the IRQ handler when shutting down the device or making major > configuration changes to the chip. > > The idea I came up with is a two-bit atomic bitmask. When base > level code wants to quiesce interrupt processing, it takes the > necessary driver spinlocks, sets the "SYNC" bit in the bitmask, > forces and IRQ to be asserted by the tg3 card, then waits for the > COMPLETE bit to get set by the interrupt handler. > During light testing, I found a race condition that caused tg3_irq_quiesce() to spin forever. The race condition is shown below. CPU1 CPU2 tg3_interrupt_tagged() tg3_netif_stop() netif_poll_disable() netif_rx_schedule() will do nothing tg3_full_lock() tg3_irq_quiesce() Because netif_poll_disable() is called, netif_rx_schedule() will do nothing in the interrupt handler. As a result, tg3_poll() will never be called to re-enable interrupts. Since interrupts are disabled, tg3_irq_quiesce() will not be able to set the interrupts and cause the interrupt handler to be called again, and therefore will wait forever. Even adding another call to tg3_irq_sync() at the end of the interrupt handler does not eliminate the race condition. I suppose we can enable interrupts in tg3_irq_quiesce() after setting the SYNC bit. From shemminger@osdl.org Wed Jun 1 14:38:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 14:38:41 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51LcbXq014435 for ; Wed, 1 Jun 2005 14:38:37 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j51LbZjA032260 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Jun 2005 14:37:35 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j51LbYcg019087; Wed, 1 Jun 2005 14:37:35 -0700 Date: Wed, 1 Jun 2005 14:37:34 -0700 From: Stephen Hemminger To: Gertjan van Wingerde Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] ieee80211: Update generic definitions to latest specs. Message-ID: <20050601143734.3b7a49ca@dxpl.pdx.osdl.net> In-Reply-To: <429E1FAB.6080503@home.nl> References: <429E1FAB.6080503@home.nl> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 01 Jun 2005 22:50:51 +0200 Gertjan van Wingerde wrote: > Hi, > > Attached patch updates the definitions of the generic ieee80211 stack to > the latest versions of the published 802.11x specification suite. > Please review and apply. > > Signed-off-by: Gertjan van Wingerde > Could you change the elements that fix to be enum's instead of define's example: /* Management Frame Information Element Types */ enum ieee80211_mfie { MFIE_TYPE_SSID = 0, MFIE_TYPE_RATES = 1, MFIE_TYPE_FH_SET= 2, ... From shemminger@osdl.org Wed Jun 1 14:42:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 14:42:28 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51LgOXq015034 for ; Wed, 1 Jun 2005 14:42:24 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j51LfNjA032676 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Jun 2005 14:41:24 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j51LfN66019413; Wed, 1 Jun 2005 14:41:23 -0700 Date: Wed, 1 Jun 2005 14:41:23 -0700 From: Stephen Hemminger To: Andy Fleming Cc: Netdev , Embedded PPC Linux list , Kumar Gala Subject: Re: RFC: PHY Abstraction Layer II Message-ID: <20050601144123.2bc11c06@dxpl.pdx.osdl.net> In-Reply-To: <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Wed, 1 Jun 2005 15:45:26 -0500 Andy Fleming wrote: > > On May 31, 2005, at 12:59, Stephen Hemminger wrote: > > > Here are some patches: > > * allow phy's to be modules > > * use driver owner for ref count > > * make local functions static where ever possible > > I agree with all these. > > > * get rid of bus read may sleep implication in comment. > > since you are holding phy spin lock it better not!! > On a different note, I am not sure that using sysfs/kobject bus object is the right thing for this object. Isn't the phy instance really just an kobject whose parent is the network device? I can't see a 1 to N relationship between phy bus and phy objects existing. The main use I can see for being a driver object is to catch suspend/resume, and wouldn't you want that to be tied to the network device. From davem@davemloft.net Wed Jun 1 15:22:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 15:23:02 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51MMwXq017804 for ; Wed, 1 Jun 2005 15:22:59 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Ddbag-0004kn-VP; Wed, 01 Jun 2005 15:21:35 -0700 Date: Wed, 01 Jun 2005 15:21:34 -0700 (PDT) Message-Id: <20050601.152134.120445266.davem@davemloft.net> To: mchan@broadcom.com Cc: netdev@oss.sgi.com Subject: Re: Locking model for NAPI drivers From: "David S. Miller" In-Reply-To: <1117658019.4310.58.camel@rh4> References: <20050531.154847.63995530.davem@davemloft.net> <1117658019.4310.58.camel@rh4> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev From: "Michael Chan" Date: Wed, 01 Jun 2005 13:33:39 -0700 > I suppose we can enable interrupts in tg3_irq_quiesce() after setting > the SYNC bit. Since the caller shuts down NAPI ->poll(), after setting the SYNC bit we can just check the MAILBOX register, and if a '1' is there just return. Does one need to mask out the upper bits of the regiser in order to avoid seeing the IRQ tag in such a comparison? Another potential problem is if the chip is hung for some reason, and even though an interrupt is asserted it does not send the interrupt. We'd hang in this case as well. Therefore it may be wise to add a timeout to the COMPLETE bit polling loop in order to handle such cases properly. From mchan@broadcom.com Wed Jun 1 15:32:55 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 15:32:58 -0700 (PDT) Received: from MMS2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51MWsXq018653 for ; Wed, 1 Jun 2005 15:32:55 -0700 Received: from 10.10.64.121 by MMS2.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Wed, 01 Jun 2005 15:31:50 -0700 X-Server-Uuid: 1F20ACF3-9CAF-44F7-AB47-F294E2D5B4EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Wed, 1 Jun 2005 15:31:49 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BBP11233; Wed, 1 Jun 2005 15:31:45 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA24578; Wed, 1 Jun 2005 15:31:45 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jun 2005 22:31:45 +0000 Received: from rh4 by nt-irva-0741; 01 Jun 2005 14:34:10 -0700 Subject: Re: Locking model for NAPI drivers From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com In-Reply-To: <20050601.152134.120445266.davem@davemloft.net> References: <20050531.154847.63995530.davem@davemloft.net> <1117658019.4310.58.camel@rh4> <20050601.152134.120445266.davem@davemloft.net> Date: Wed, 01 Jun 2005 14:34:10 -0700 Message-ID: <1117661650.4310.62.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E80E8DC1VO4417184-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1954 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev On Wed, 2005-06-01 at 15:21 -0700, David S. Miller wrote: > From: "Michael Chan" > Date: Wed, 01 Jun 2005 13:33:39 -0700 > > > I suppose we can enable interrupts in tg3_irq_quiesce() after setting > > the SYNC bit. > > Since the caller shuts down NAPI ->poll(), after setting the SYNC bit > we can just check the MAILBOX register, and if a '1' is there just > return. Does one need to mask out the upper bits of the regiser in > order to avoid seeing the IRQ tag in such a comparison? > No, just check for the value 1 since that's the value we use to disable interrupts. The value read back will always be 1 if 1 was previously written to it. From afleming@freescale.com Wed Jun 1 15:38:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 15:38:03 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51MbxXq019309 for ; Wed, 1 Jun 2005 15:37:59 -0700 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.12.11/az33egw02) with ESMTP id j51Mf5oC009076; Wed, 1 Jun 2005 15:41:06 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j51Me9Xo018231; Wed, 1 Jun 2005 17:40:10 -0500 (CDT) In-Reply-To: <20050601144123.2bc11c06@dxpl.pdx.osdl.net> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> <20050601144123.2bc11c06@dxpl.pdx.osdl.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A2D608A-D818-455B-96F4-ED42413556C0@freescale.com> Cc: Netdev , Embedded PPC Linux list , Kumar Gala Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 1 Jun 2005 17:36:54 -0500 To: Stephen Hemminger X-Mailer: Apple Mail (2.730) X-archive-position: 1955 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev On Jun 1, 2005, at 16:41, Stephen Hemminger wrote: > On Wed, 1 Jun 2005 15:45:26 -0500 > Andy Fleming wrote: >> >>> * get rid of bus read may sleep implication in comment. >>> since you are holding phy spin lock it better not!! >>> >> >> > > On a different note, I am not sure that using sysfs/kobject bus object > is the right thing for this object. Isn't the phy instance really > just > an kobject whose parent is the network device? I can't see a 1 to N > relationship between phy bus and phy objects existing. Well, the MII Management bus is, in fact, a bus. When a network driver wants to modify a PHY, it must access that bus. Many ethernet controllers have a 1 to 1 relationship, since a typical NIC is a PCI card with 1 ethernet port (meaning one controller, and one PHY). However, many systems have multiple ethernet controllers attached to one bus, which configures multiple PHYs. Currently, these systems have been relying on luck to prevent multiple accesses to the same bus. This tends to work because all of the PHY support is contained within the ethernet driver, so it is easy for such drivers to ensure that only one PHY transaction is done at a time. This system begins to fall apart, though, when the PHY drivers start operating more independently to react to changing PHY state. It really begins to fall apart if you have multiple drivers trying to access a shared bus. For instance, the 8560 ADS board has 2 gigabit ethernet ports controlled by the gianfar driver, and 2 10/100 ports in the CPM subsystem, controlled by the fcc_enet driver. These two drivers each have an access point for the bus, which use different mechanisms (one is a bit bang interface, and one is register based). Using the new abstraction, it is possible for the FCC driver to use the gianfar driver's bus, thus saving code, and reducing complexity. > > The main use I can see for being a driver object is to catch > suspend/resume, > and wouldn't you want that to be tied to the network device. It would be quite easy for the network driver to suspend or resume the PHY and bus objects under the new abstraction. However, if eth0 is suspended, should it suspend the whole bus, and all the PHYs on it? By making the MII bus an independent entity, eth0 can be suspended, and it can choose to suspend its PHY, but eth1 can continue to access its PHY over the bus, since those aren't suspended. From afleming@freescale.com Wed Jun 1 15:43:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 15:44:01 -0700 (PDT) Received: from az33egw01.freescale.net (az33egw01.freescale.net [192.88.158.102]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j51MhwXq020018 for ; Wed, 1 Jun 2005 15:43:58 -0700 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw01.freescale.net (8.12.11/az33egw01) with ESMTP id j51MmPBu017065; Wed, 1 Jun 2005 15:48:25 -0700 (MST) Received: from [10.82.17.56] ([10.82.17.56]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id j51MkCFY019534; Wed, 1 Jun 2005 17:46:12 -0500 (CDT) In-Reply-To: <429E2653.6010101@osdl.org> References: <1107b64b01fb8e9a6c84359bb56881a6@freescale.com> <20050531105939.7486e071@dxpl.pdx.osdl.net> <92F1428A-0B26-428B-8C06-35C7E5B9EEE3@freescale.com> <429E2653.6010101@osdl.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Netdev , Embedded PPC Linux list , Kumar Gala Content-Transfer-Encoding: 7bit From: Andy Fleming Subject: Re: RFC: PHY Abstraction Layer II Date: Wed, 1 Jun 2005 17:42:56 -0500 To: Stephen Hemminger X-Mailer: Apple Mail (2.730) X-archive-position: 1956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: afleming@freescale.com Precedence: bulk X-list: netdev On Jun 1, 2005, at 16:19, Stephen Hemminger wrote: > Andy Fleming wrote: >> >> But not this one. The phy_read and phy_write functions are >> reading from and writing to a bus. It is a reasonable >> implementation to have the operation block in the bus driver, and >> be awoken when an interrupt signals the operation is done. All >> of the phydev spinlocks have been arranged so as to prevent the >> lock being taken during interrupt time. >> >> Unless I've misunderstood spinlocks (it wouldn't be the first >> time), as long as the lock is never taken in interrupt time, it >> should be ok to hold the lock, and wait for an interrupt before >> clearing the lock. >> > > > The problem is that sleeping is defined in the linux kernel as > meaning waiting on a mutual exclusion > primitive (like semaphore) that puts the current thread to sleep. > It is not legal to sleep with a spinlock held. > In the phy_read code you do: > spin_lock_bh(&bus->mdio_lock); > retval = bus->read(bus, phydev->addr, regnum); > spin_unlock_bh(&bus->mdio_lock); > > If the bus->read function were to do something like start a request > and wait on a semaphore, then > you would be sleeping with a spin lock held. So bus->read can not > sleep! (as sleep is defined in the > linux kernel). Hmm... I understand this reasoning, but I still need a way for a bus read to wait for an interrupt before returning. I suppose I can just have the code spin while it waits, but that seems wrong, somehow. I'm open to any suggestions. From gwingerde@home.nl Wed Jun 1 20:55:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 20:55:50 -0700 (PDT) Received: from smtpq1.home.nl (smtpq1.home.nl [213.51.128.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j523thXq012188 for ; Wed, 1 Jun 2005 20:55:46 -0700 Received: from [213.51.128.134] (port=59856 helo=smtp3.home.nl) by smtpq1.home.nl with esmtp (Exim 4.30) id 1Ddgn8-0007D7-Al; Thu, 02 Jun 2005 05:54:46 +0200 Received: from cc10088-a.ensch1.ov.home.nl ([217.123.128.105]:59933 helo=[192.168.14.1]) by smtp3.home.nl with esmtp (Exim 4.30) id 1Ddgn6-00071G-DC; Thu, 02 Jun 2005 05:54:44 +0200 Message-ID: <429E8175.7010609@home.nl> Date: Thu, 02 Jun 2005 05:48:05 +0200 From: Gertjan van Wingerde User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] ieee80211: Update generic definitions to latest specs. References: <429E1FAB.6080503@home.nl> <20050601143734.3b7a49ca@dxpl.pdx.osdl.net> In-Reply-To: <20050601143734.3b7a49ca@dxpl.pdx.osdl.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean X-archive-position: 1958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev Stephen Hemminger wrote: >On Wed, 01 Jun 2005 22:50:51 +0200 >Gertjan van Wingerde wrote: > > > >>Hi, >> >>Attached patch updates the definitions of the generic ieee80211 stack to >>the latest versions of the published 802.11x specification suite. >>Please review and apply. >> >>Signed-off-by: Gertjan van Wingerde >> >> >> >Could you change the elements that fix to be enum's instead of define's > >example: > >/* Management Frame Information Element Types */ >enum ieee80211_mfie { > MFIE_TYPE_SSID = 0, > MFIE_TYPE_RATES = 1, > MFIE_TYPE_FH_SET= 2, >... > Hi Stephen, Well, my patch is really just an add-on to the existing code. Converting to enums is really a follow-up patch that can be applied on top of this one. I'm happy to produce a patch if everybody agrees. Jeff, any opinions on this? Best regards, Gertjan. From raghunathan.venkatesan@wipro.com Wed Jun 1 20:54:49 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 01 Jun 2005 20:54:52 -0700 (PDT) Received: from wip-ec-wd.wipro.com (wip-ec-wd.wipro.com [203.101.113.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j523sjXq012029 for ; Wed, 1 Jun 2005 20:54:48 -0700 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id CA4D8205E7; Thu, 2 Jun 2005 09:14:50 +0530 (IST) Received: from blr-ec-bh01.wipro.com (unknown [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id B055A205E5; Thu, 2 Jun 2005 09:14:50 +0530 (IST) Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 09:23:44 +0530 Received: from CHN-SNR-MBX01.wipro.com ([10.145.50.181]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Jun 2005 09:23:43 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Unable to handle kernel paging request at virtual address 04000460 Date: Thu, 2 Jun 2005 09:20:21 +0530 Message-ID: <438662DA48DCAA41B1DF648BD4BD76C0E461B8@CHN-SNR-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unable to handle kernel paging request at virtual address 04000460 Thread-Index: AcVm23XgN0MUhNi8RfmehJZdjhz+YAASlBxQ From: To: Cc: , , X-OriginalArrivalTime: 02 Jun 2005 03:53:43.0508 (UTC) FILETIME=[AB960140:01C56726] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j523sjXq012029 X-archive-position: 1957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: raghunathan.venkatesan@wipro.com Precedence: bulk X-list: netdev Hi David, I understand that the linux community may not be able to debug it for me. All I require is if people have seen similar problems (the problems we face are w.r.t to kfree_skb and skb_drop_fraglist crashing due to some reason, which could be a Memory Management issue or some thing we are not aware of), then let us know the patches, so that we can try them out here. Thankyou for your response. Regards, Raghu -----Original Message----- From: David S. Miller [mailto:davem@davemloft.net] Sent: Thursday, June 02, 2005 12:25 AM To: Raghunathan Venkatesan (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS) Cc: linux-net@vger.kernel.org; netdev@oss.sgi.com; linux@der-keiler.de Subject: Re: Unable to handle kernel paging request at virtual address 04000460 Please don't ask the community to debug your custom kernel with private VPN driver modules installed. From herbert@gondor.apana.org.au Thu Jun 2 02:45:17 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 02:45:22 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j529jEXq000794 for ; Thu, 2 Jun 2005 02:45:15 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DdmFD-0007y2-00; Thu, 02 Jun 2005 19:44:07 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DdmFA-0006o5-00; Thu, 02 Jun 2005 19:44:04 +1000 Date: Thu, 2 Jun 2005 19:44:04 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [IPV4/IPV6] Replace spin_lock_irq with spin_lock_bh Message-ID: <20050602094404.GA10316@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1959 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: In light of my recent patch to net/ipv4/udp.c that replaced the spin_lock_irq calls on the receive queue lock with spin_lock_bh, here is a similar patch for all other occurences of spin_lock_irq on receive/error queue locks in IPv4 and IPv6. In these stacks, we know that they can only be entered from user or softirq context. Therefore it's safe to disable BH only. Signed-off-by: Herbert Xu Since this patch simply improves the consistent use of locking primitives rather fixing any real bugs, it should probably go into net-2.6.13. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c --- a/net/ipv4/ip_sockglue.c +++ b/net/ipv4/ip_sockglue.c @@ -360,14 +360,14 @@ int ip_recv_error(struct sock *sk, struc err = copied; /* Reset and regenerate socket error */ - spin_lock_irq(&sk->sk_error_queue.lock); + spin_lock_bh(&sk->sk_error_queue.lock); sk->sk_err = 0; if ((skb2 = skb_peek(&sk->sk_error_queue)) != NULL) { sk->sk_err = SKB_EXT_ERR(skb2)->ee.ee_errno; - spin_unlock_irq(&sk->sk_error_queue.lock); + spin_unlock_bh(&sk->sk_error_queue.lock); sk->sk_error_report(sk); } else - spin_unlock_irq(&sk->sk_error_queue.lock); + spin_unlock_bh(&sk->sk_error_queue.lock); out_free_skb: kfree_skb(skb); diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -691,11 +691,11 @@ static int raw_ioctl(struct sock *sk, in struct sk_buff *skb; int amount = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); if (skb != NULL) amount = skb->len; - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); return put_user(amount, (int __user *)arg); } diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c --- a/net/ipv6/datagram.c +++ b/net/ipv6/datagram.c @@ -353,14 +353,14 @@ int ipv6_recv_error(struct sock *sk, str err = copied; /* Reset and regenerate socket error */ - spin_lock_irq(&sk->sk_error_queue.lock); + spin_lock_bh(&sk->sk_error_queue.lock); sk->sk_err = 0; if ((skb2 = skb_peek(&sk->sk_error_queue)) != NULL) { sk->sk_err = SKB_EXT_ERR(skb2)->ee.ee_errno; - spin_unlock_irq(&sk->sk_error_queue.lock); + spin_unlock_bh(&sk->sk_error_queue.lock); sk->sk_error_report(sk); } else { - spin_unlock_irq(&sk->sk_error_queue.lock); + spin_unlock_bh(&sk->sk_error_queue.lock); } out_free_skb: diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c +++ b/net/ipv6/raw.c @@ -434,12 +434,12 @@ csum_copy_err: /* Clear queue. */ if (flags&MSG_PEEK) { int clear = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); if (skb == skb_peek(&sk->sk_receive_queue)) { __skb_unlink(skb, &sk->sk_receive_queue); clear = 1; } - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); if (clear) kfree_skb(skb); } @@ -971,11 +971,11 @@ static int rawv6_ioctl(struct sock *sk, struct sk_buff *skb; int amount = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); if (skb != NULL) amount = skb->tail - skb->h.raw; - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); return put_user(amount, (int __user *)arg); } diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -300,12 +300,12 @@ csum_copy_err: /* Clear queue. */ if (flags&MSG_PEEK) { int clear = 0; - spin_lock_irq(&sk->sk_receive_queue.lock); + spin_lock_bh(&sk->sk_receive_queue.lock); if (skb == skb_peek(&sk->sk_receive_queue)) { __skb_unlink(skb, &sk->sk_receive_queue); clear = 1; } - spin_unlock_irq(&sk->sk_receive_queue.lock); + spin_unlock_bh(&sk->sk_receive_queue.lock); if (clear) kfree_skb(skb); } --cWoXeonUoKmBZSoM-- From herbert@gondor.apana.org.au Thu Jun 2 02:56:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 02:56:10 -0700 (PDT) Received: from arnor.apana.org.au (arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j529u2Xq001566 for ; Thu, 2 Jun 2005 02:56:03 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1DdmPm-00084I-00; Thu, 02 Jun 2005 19:55:02 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1DdmPj-0007pT-00; Thu, 02 Jun 2005 19:54:59 +1000 Date: Thu, 2 Jun 2005 19:54:59 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [SCTP] Replace spin_lock_irqsave with spin_lock_bh Message-ID: <20050602095459.GA26638@gondor.apana.org.au> References: <20050602094404.GA10316@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20050602094404.GA10316@gondor.apana.org.au> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 1960 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This patch replaces the spin_lock_irqsave call on the receive queue lock in SCTP with spin_lock_bh. Despite the proliferation of spin_lock_irqsave calls in this stack, it is only entered from the IPv4/IPv6 stack and user space. That is, it is never entered from hardirq context. The call in question is only called from recvmsg which means that IRQs aren't disabled. Therefore it is safe to replace it with spin_lock_bh. Signed-off-by: Herbert Xu As before, this should probably only go into net-2.6.13. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff --git a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -4368,15 +4368,11 @@ static struct sk_buff *sctp_skb_recv_dat * However, this function was corrent in any case. 8) */ if (flags & MSG_PEEK) { - unsigned long cpu_flags; - - sctp_spin_lock_irqsave(&sk->sk_receive_queue.lock, - cpu_flags); + spin_lock_bh(&sk->sk_receive_queue.lock); skb = skb_peek(&sk->sk_receive_queue); if (skb) atomic_inc(&skb->users); - sctp_spin_unlock_irqrestore(&sk->sk_receive_queue.lock, - cpu_flags); + spin_unlock_bh(&sk->sk_receive_queue.lock); } else { skb = skb_dequeue(&sk->sk_receive_queue); } --2oS5YaxWCcQjTEyO-- From jtbbesaa@bipt106.bi.ehu.es Thu Jun 2 03:40:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 03:40:04 -0700 (PDT) Received: from bipt106.bi.ehu.es (bipt106.bi.ehu.es [158.227.67.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52AdsXq003451 for ; Thu, 2 Jun 2005 03:39:59 -0700 Received: from bipt54.bi.ehu.es ([158.227.75.54] helo=ibook.ziberghetto.dhis.org) by bipt106.bi.ehu.es with esmtp (Exim 3.35 #1 (Debian)) id 1Ddn6I-0002Yr-00; Thu, 02 Jun 2005 12:38:58 +0200 Received: by ibook.ziberghetto.dhis.org (Postfix, from userid 1000) id 1D9BB20F1F; Thu, 2 Jun 2005 12:38:26 +0200 (CEST) From: Alfredo Beaumont Sainz Organization: Euskal Herriko Unibertsitatea To: netdev@oss.sgi.com Subject: Problems with Broadcom and Intel PRO/1000 cards Date: Thu, 2 Jun 2005 12:38:19 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2076079.6N4Hu5pznk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es> X-archive-position: 1961 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jtbbesaa@bipt106.bi.ehu.es Precedence: bulk X-list: netdev --nextPart2076079.6N4Hu5pznk Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I've a dual opteron machine with an integrated dual Broadcom 5704 10/100/10= 00=20 (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It seems that I canno= t=20 make them work a Gbps. I've a crossover cable connecting a interface of the= =20 Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps: # /sbin/mii-tool -v eth1: negotiated 100baseTx-FD, link ok product info: vendor 00:08:18, model 25 rev 0 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD eth2: negotiated 100baseTx-FD, link ok product info: vendor 00:50:43, model 2 rev 5 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control As you can see, there's no 1000 FD advsertising. Forcing it with ethtool ma= kes=20 them lose link connection: # /usr/sbin/ethtool -s eth1 speed 1000 duplex full # /sbin/mii-tool -v eth1: no link product info: vendor 00:08:18, model 25 rev 0 basic mode: autonegotiation enabled basic status: no link capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD eth2: no link product info: vendor 00:50:43, model 2 rev 5 basic mode: autonegotiation enabled basic status: no link capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control After some secs link is recovered, at 100 again, and dmesg shows the follow= ing=20 kernel messages: tg3: eth1: Link is down. e1000: eth2: e1000_watchdog: NIC Link is Down tg3: eth1: Link is up at 1000 Mbps, full duplex. tg3: eth1: Flow control is off for TX and off for RX. e1000: eth2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex According to the messages links would be at 1000 but they are not really. T= he=20 same happens when forcing eth2. I'm using kernel version 2.6.11.11 but it also happened with previous versi= on=20 of the kernel. Any hints? Thanks. =2D-=20 Alfredo Beaumont. GPG: http://aintel.bi.ehu.es/~jtbbesaa/jtbbesaa.gpg.asc Elektronika eta Telekomunikazioak Saila (Ingeniaritza Telematikoa) Euskal Herriko Unibertsitatea, Bilbao (Basque Country). http://www.ehu.es --nextPart2076079.6N4Hu5pznk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCnuGh6KTU/EgLc1ERAgOsAJ9Bs8oPJEelifI+GtiP62cMEfl8ZQCfXxc6 e2z/CGhpOy0qWoXNj22/SMQ= =4LuQ -----END PGP SIGNATURE----- --nextPart2076079.6N4Hu5pznk-- From postman@harrier.cohaesio.com Thu Jun 2 04:34:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 04:34:19 -0700 (PDT) Received: from harrier.cohaesio.com (harrier.cohaesio.com [212.97.128.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52BYFXq009978 for ; Thu, 2 Jun 2005 04:34:16 -0700 Received: by harrier.cohaesio.com (Postfix, from userid 88) id 7BF0647; Thu, 2 Jun 2005 13:33:14 +0200 (CEST) X-Original-To: news2mail@news.cohaesio.com Delivered-To: news2mail@news.cohaesio.com From: "Anders K. Pedersen" Subject: Re: Problems with Broadcom and Intel PRO/1000 cards Date: Thu, 02 Jun 2005 13:34:09 +0200 Organization: Cohaesio A/S Lines: 13 Message-ID: References: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: harrier.cohaesio.com 1117711993 26359 212.97.128.136 (2 Jun 2005 11:33:13 GMT) X-Complaints-To: newsmaster@news.cohaesio.com X-Accept-Language: en-us, en To: netdev@oss.sgi.com X-archive-position: 1962 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akp@cohaesio.com Precedence: bulk X-list: netdev Alfredo Beaumont Sainz wrote: > I've a dual opteron machine with an integrated dual Broadcom 5704 10/100/1000 > (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It seems that I cannot > make them work a Gbps. I've a crossover cable connecting a interface of the > Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps: > > # /sbin/mii-tool -v mii-tool does not (yet) support more than 100 Mbit/s, so it will report a 1000 Mbit/s connection as only running 100 Mbit/s. Use ethtool for now. Regards, Anders K. Pedersen From bunk@stusta.de Thu Jun 2 05:16:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 05:16:26 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j52CGMXq011914 for ; Thu, 2 Jun 2005 05:16:23 -0700 Received: (qmail 16519 invoked from network); 2 Jun 2005 12:15:12 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 2 Jun 2005 12:15:12 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 6DB05BB5F8; Thu, 2 Jun 2005 14:15:11 +0200 (CEST) Date: Thu, 2 Jun 2005 14:15:11 +0200 From: Adrian Bunk To: Andrew Morton , shemminger@osdl.org Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages Message-ID: <20050602121511.GE4992@stusta.de> References: <20050601022824.33c8206e.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601022824.33c8206e.akpm@osdl.org> User-Agent: Mutt/1.5.9i X-archive-position: 1963 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote: >... > Changes since 2.6.12-rc5-mm1: >... > +tcp-tcp_infra.patch >... > Steve Hemminger's TCP enhancements. >... I said "no" to CONFIG_TCP_CONG_BIC, and now my syslog is full of messages kernel: bic unavailable using TCP reno I have no problem with such a message being shown once - but once should be enough. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From hadi@cyberus.ca Thu Jun 2 05:27:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 05:27:55 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52CRkXq012728 for ; Thu, 2 Jun 2005 05:27:47 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Ddomh-0004kV-UR for netdev@oss.sgi.com; Thu, 02 Jun 2005 08:26:51 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Ddomg-0006iO-KG; Thu, 02 Jun 2005 08:26:50 -0400 Subject: Re: RFC: NAPI packet weighting patch From: jamal Reply-To: hadi@cyberus.ca To: Jon Mason Cc: "David S. Miller" , mitch.a.williams@intel.com, shemminger@osdl.org, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com In-Reply-To: <200505311828.44304.jdmason@us.ibm.com> References: <1117241786.6251.7.camel@localhost.localdomain> <200505311707.54487.jdmason@us.ibm.com> <20050531.151443.74564699.davem@davemloft.net> <200505311828.44304.jdmason@us.ibm.com> Content-Type: text/plain Organization: unknown Date: Thu, 02 Jun 2005 08:26:46 -0400 Message-Id: <1117715207.6050.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1964 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-31-05 at 18:28 -0500, Jon Mason wrote: > On Tuesday 31 May 2005 05:14 pm, David S. Miller wrote: > > From: Jon Mason > > Date: Tue, 31 May 2005 17:07:54 -0500 > > > > > Of course some performace analysis would have to be done to determine the > > > optimal numbers for each speed/duplexity setting per driver. > > > > per cpu speed, per memory bus speed, per I/O bus speed, and add in other > > complications such as NUMA > > > > My point is that whatever experimental number you come up with will be > > good for that driver on your systems, not necessarily for others. > > > > Even within a system, whatever number you select will be the wrong > > thing to use if one starts a continuous I/O stream to the SATA > > controller in the next PCI slot, for example. > > > > We keep getting bitten by this, as the Altix perf data continually shows, > > and we need to absolutely stop thinking this way. > > > > The way to go is to make selections based upon observed events and > > mesaurements. > > I'm not arguing against a /proc entry to tune dev->weight for those sysadmins > advanced enough to do that. I am arguing that we can make the driver smarter > (at little/no cost) for "out of the box" users. > What is the point of making the driver "smarter"? Recall, the algorithm used to schedule the netdevices is based on an extension of Weighted Round Robin from Varghese et al known as DRR (ask gooogle for details). The idea is to provide fairness amongst many drivers. As an example, if you have a gige driver it shouldnt be taking all the resources at the expense of starving the fastether driver. If the admin wants one driver to be more "important" than the other, s/he will make sure it has a higher weight. cheers, jamal From hadi@cyberus.ca Thu Jun 2 06:05:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 06:06:04 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52D5rXq015814 for ; Thu, 2 Jun 2005 06:05:57 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DdpNa-0004ha-Tm for netdev@oss.sgi.com; Thu, 02 Jun 2005 09:04:58 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DdpNY-0004wq-08; Thu, 02 Jun 2005 09:04:56 -0400 Subject: PATCH: explicit typing WAS(Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: tgraf@suug.ch, netdev@oss.sgi.com In-Reply-To: <20050531.153125.95894437.davem@davemloft.net> References: <1117197157.6688.24.camel@localhost.localdomain> <20050531.144338.112623594.davem@davemloft.net> <20050531222646.GK15391@postel.suug.ch> <20050531.153125.95894437.davem@davemloft.net> Content-Type: multipart/mixed; boundary="=-MNGFh9ieSNAM2tZgwH9J" Organization: unknown Date: Thu, 02 Jun 2005 09:04:52 -0400 Message-Id: <1117717493.6050.29.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 1965 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev --=-MNGFh9ieSNAM2tZgwH9J Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-31-05 at 15:31 -0700, David S. Miller wrote: > From: Thomas Graf > Date: Wed, 1 Jun 2005 00:26:46 +0200 > > > > Please use explicit "unsigned int flags" instead of "unsigned flags". > > > > I converted this already in the two patches later in the thread. > > I see, thanks for pointing this out. > If you want to do it right, it should be a u16 actually ;-> In any case since we are being gracious - lets fix where i cutnpasted it from using TheLinuxWay ;-> ------------- This patch converts "unsigned flags" to use more explict types like u16 instead and incrementally introduces NLMSG_NEW(). Signed-off-by: Jamal Hadi Salim cheers, jamal --=-MNGFh9ieSNAM2tZgwH9J Content-Disposition: attachment; filename=expl_p Content-Type: text/plain; name=expl_p; charset=UTF-8 Content-Transfer-Encoding: 7bit net/ipv6/addrconf.c: needs update net/sched/act_api.c: needs update net/sched/cls_api.c: needs update net/sched/sch_api.c: needs update Index: net/ipv6/addrconf.c =================================================================== --- faa2ccd541211d62ece040534da95da9476d4f14/net/ipv6/addrconf.c (mode:100644) +++ uncommitted/net/ipv6/addrconf.c (mode:100644) @@ -131,7 +131,7 @@ static int addrconf_ifdown(struct net_device *dev, int how); -static void addrconf_dad_start(struct inet6_ifaddr *ifp, int flags); +static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags); static void addrconf_dad_timer(unsigned long data); static void addrconf_dad_completed(struct inet6_ifaddr *ifp); static void addrconf_rs_timer(unsigned long data); @@ -491,7 +491,7 @@ static struct inet6_ifaddr * ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr, int pfxlen, - int scope, unsigned flags) + int scope, u32 flags) { struct inet6_ifaddr *ifa = NULL; struct rt6_info *rt; @@ -1319,7 +1319,7 @@ static void addrconf_prefix_route(struct in6_addr *pfx, int plen, struct net_device *dev, - unsigned long expires, unsigned flags) + unsigned long expires, u32 flags) { struct in6_rtmsg rtmsg; @@ -2228,7 +2228,7 @@ /* * Duplicate Address Detection */ -static void addrconf_dad_start(struct inet6_ifaddr *ifp, int flags) +static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags) { struct inet6_dev *idev = ifp->idev; struct net_device *dev = idev->dev; @@ -2670,7 +2670,7 @@ } static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca, - u32 pid, u32 seq, int event, unsigned flags) + u32 pid, u32 seq, int event, u16 flags) { struct ifaddrmsg *ifm; struct nlmsghdr *nlh; Index: net/sched/act_api.c =================================================================== --- faa2ccd541211d62ece040534da95da9476d4f14/net/sched/act_api.c (mode:100644) +++ uncommitted/net/sched/act_api.c (mode:100644) @@ -428,15 +428,15 @@ static int tca_get_fill(struct sk_buff *skb, struct tc_action *a, u32 pid, u32 seq, - unsigned flags, int event, int bind, int ref) + u16 flags, int event, int bind, int ref) { struct tcamsg *t; struct nlmsghdr *nlh; unsigned char *b = skb->tail; struct rtattr *x; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*t)); - nlh->nlmsg_flags = flags; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*t), flags); + t = NLMSG_DATA(nlh); t->tca_family = AF_UNSPEC; @@ -669,7 +669,7 @@ } static int tcf_add_notify(struct tc_action *a, u32 pid, u32 seq, int event, - unsigned flags) + u16 flags) { struct tcamsg *t; struct nlmsghdr *nlh; @@ -684,8 +684,7 @@ b = (unsigned char *)skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*t)); - nlh->nlmsg_flags = flags; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*t), flags); t = NLMSG_DATA(nlh); t->tca_family = AF_UNSPEC; Index: net/sched/cls_api.c =================================================================== --- faa2ccd541211d62ece040534da95da9476d4f14/net/sched/cls_api.c (mode:100644) +++ uncommitted/net/sched/cls_api.c (mode:100644) @@ -322,14 +322,13 @@ static int tcf_fill_node(struct sk_buff *skb, struct tcf_proto *tp, unsigned long fh, - u32 pid, u32 seq, unsigned flags, int event) + u32 pid, u32 seq, u16 flags, int event) { struct tcmsg *tcm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm)); - nlh->nlmsg_flags = flags; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags); tcm = NLMSG_DATA(nlh); tcm->tcm_family = AF_UNSPEC; tcm->tcm_ifindex = tp->q->dev->ifindex; Index: net/sched/sch_api.c =================================================================== --- faa2ccd541211d62ece040534da95da9476d4f14/net/sched/sch_api.c (mode:100644) +++ uncommitted/net/sched/sch_api.c (mode:100644) @@ -760,15 +760,14 @@ } static int tc_fill_qdisc(struct sk_buff *skb, struct Qdisc *q, u32 clid, - u32 pid, u32 seq, unsigned flags, int event) + u32 pid, u32 seq, u16 flags, int event) { struct tcmsg *tcm; struct nlmsghdr *nlh; unsigned char *b = skb->tail; struct gnet_dump d; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm)); - nlh->nlmsg_flags = flags; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags); tcm = NLMSG_DATA(nlh); tcm->tcm_family = AF_UNSPEC; tcm->tcm_ifindex = q->dev->ifindex; @@ -997,7 +996,7 @@ static int tc_fill_tclass(struct sk_buff *skb, struct Qdisc *q, unsigned long cl, - u32 pid, u32 seq, unsigned flags, int event) + u32 pid, u32 seq, u16 flags, int event) { struct tcmsg *tcm; struct nlmsghdr *nlh; @@ -1005,8 +1004,7 @@ struct gnet_dump d; struct Qdisc_class_ops *cl_ops = q->ops->cl_ops; - nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*tcm)); - nlh->nlmsg_flags = flags; + nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*tcm), flags); tcm = NLMSG_DATA(nlh); tcm->tcm_family = AF_UNSPEC; tcm->tcm_ifindex = q->dev->ifindex; --=-MNGFh9ieSNAM2tZgwH9J-- From abonilla@linuxwireless.org Thu Jun 2 06:06:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 06:06:22 -0700 (PDT) Received: from linuxwireless.org.ve.carpathiahost.net (linuxwireless.org.ve.carpathiahost.net [66.117.45.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52D6EXq015848 for ; Thu, 2 Jun 2005 06:06:15 -0700 Received: from WCRSJO2KPAB047 ([200.9.49.66]) by linuxwireless.org.ve.carpathiahost.net (8.12.10/8.12.10) with SMTP id j52D4vgC001796; Thu, 2 Jun 2005 09:04:58 -0400 Reply-To: From: "Alejandro Bonilla" To: "'Alfredo Beaumont Sainz'" , Subject: RE: Problems with Broadcom and Intel PRO/1000 cards Date: Thu, 2 Jun 2005 07:04:43 -0600 Message-ID: <001c01c56773$a5684060$600cc60a@amer.sykes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-archive-position: 1966 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: abonilla@linuxwireless.org Precedence: bulk X-list: netdev > Hi, > > I've a dual opteron machine with an integrated dual Broadcom > 5704 10/100/1000 > (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It > seems that I cannot > make them work a Gbps. I've a crossover cable connecting a > interface of the > Broadcom (eth1) with the Intel (eth2), but they connect at 100Mbps: > Only time that I have seen this before, it was because I was using an incorrect cable. Make sure you have the _REAL_ Gb crossover cable. http://logout.sh/computers/net/gigabit/ Also, I would trust in dmesg and not in some other tool. .Alejandro From baruch@ev-en.org Thu Jun 2 06:59:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 06:59:26 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52DxNXq020273 for ; Thu, 2 Jun 2005 06:59:24 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 9282711A953; Thu, 2 Jun 2005 16:58:24 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 9DB9D11A952; Thu, 2 Jun 2005 16:58:21 +0300 (IDT) Message-ID: <429F1079.5070701@ev-en.org> Date: Thu, 02 Jun 2005 14:58:17 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Bunk Cc: Andrew Morton , shemminger@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages References: <20050601022824.33c8206e.akpm@osdl.org> <20050602121511.GE4992@stusta.de> In-Reply-To: <20050602121511.GE4992@stusta.de> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 1967 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Adrian Bunk wrote: > On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote: > >>... >>Changes since 2.6.12-rc5-mm1: >>... >>+tcp-tcp_infra.patch >>... >> Steve Hemminger's TCP enhancements. >>... > > > I said "no" to CONFIG_TCP_CONG_BIC, and now my syslog is full of messages > kernel: bic unavailable using TCP reno > > I have no problem with such a message being shown once - but once should > be enough. The best solution for this would be to check the available protocols at setup time and not at connection creation time. This would also provide a better feedback to the user, since he will either see that what he set was taken, or it wasn't. In the current mechanism you can set the protocol to 'foo' and it will show back as 'foo'. You'll get complaints only once a connection is attempted with this protocol. It does mean some extra work in the sysctl stage, but it's better IMO to do it there rather than at connection setup time. Baruch From hadi@cyberus.ca Thu Jun 2 07:13:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 07:14:02 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52EDsXq021395 for ; Thu, 2 Jun 2005 07:13:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.30) id 1DdqRN-0007RQ-AU for netdev@oss.sgi.com; Thu, 02 Jun 2005 08:12:57 -0600 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Ddpp0-0002iM-B1; Thu, 02 Jun 2005 09:33:18 -0400 Subject: Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev@oss.sgi.com In-Reply-To: <20050531161315.GH15391@postel.suug.ch> References: <20050527151608.GZ15391@postel.suug.ch> <1117209411.6383.104.camel@localhost.localdomain> <20050527163516.GB15391@postel.suug.ch> <1117244567.6251.34.camel@localhost.localdomain> <20050528120731.GP15391@postel.suug.ch> <1117533847.6134.32.camel@localhost.localdomain> <20050531114251.GC15391@postel.suug.ch> <1117543711.6134.48.camel@localhost.localdomain> <20050531131747.GF15391@postel.suug.ch> <1117551561.6279.2.camel@localhost.localdomain> <20050531161315.GH15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Thu, 02 Jun 2005 09:33:15 -0400 Message-Id: <1117719195.6050.54.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1969 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Tue, 2005-31-05 at 18:13 +0200, Thomas Graf wrote: [..] > So what I propose is to have the neighbour table parameters, > e.g. everything in arp_tbl be distributed over RTM_NEIGHTBL > and put the device specific parameters into devconfig, > e.g. in_dev->arp_parms. > Right, this is what i am saying a well. The only caveat i was pointing out is that the devconfig piece is more than just the neighbor stuff - and of course it hasnt been written, yet;-> The major challenge will be events - some change via /proc, sysfs etc should generate event. I suggest something along usage of notifier_block with something like NETDEV_CONFIG to transport these things around. Damn, if only i can find my patch .... I had already started doing events based on changes from /proc or sysctl etc. > Absolutely, more specific: > > netdevice -> inet_device -> parameter set -> neighbour table > or: > neighbour table -> list of parameter sets -> netdevice > > both ways are possible right now. Sounds good to me. cheers, jamal From jtbbesaa@bipt106.bi.ehu.es Thu Jun 2 07:13:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 07:13:34 -0700 (PDT) Received: from bipt106.bi.ehu.es (bipt106.bi.ehu.es [158.227.67.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52EDPXq021320 for ; Thu, 2 Jun 2005 07:13:28 -0700 Received: from bipt54.bi.ehu.es ([158.227.75.54] helo=ibook.ziberghetto.dhis.org) by bipt106.bi.ehu.es with esmtp (Exim 3.35 #1 (Debian)) id 1DdqQu-0005HX-00 for ; Thu, 02 Jun 2005 16:12:28 +0200 Received: by ibook.ziberghetto.dhis.org (Postfix, from userid 1000) id 04FA121151; Thu, 2 Jun 2005 16:11:55 +0200 (CEST) From: Alfredo Beaumont Sainz Organization: Euskal Herriko Unibertsitatea To: netdev@oss.sgi.com Subject: Re: Problems with Broadcom and Intel PRO/1000 cards Date: Thu, 2 Jun 2005 16:11:42 +0200 User-Agent: KMail/1.8 References: <200506021238.25615.jtbbesaa@aintel.bi.ehu.es> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1279143.OyKeIErFOt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506021611.54933.jtbbesaa@aintel.bi.ehu.es> X-archive-position: 1968 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jtbbesaa@bipt106.bi.ehu.es Precedence: bulk X-list: netdev --nextPart1279143.OyKeIErFOt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Og, 2005eko Ekaren 02a 13:34(e)an, Anders K. Pedersen(e)k idatzi zuen: > Alfredo Beaumont Sainz wrote: > > I've a dual opteron machine with an integrated dual Broadcom 5704 > > 10/100/1000 (tg3 driver) and an Intel PRO/1000 MT (e1000 driver). It > > seems that I cannot make them work a Gbps. I've a crossover cable > > connecting a interface of the Broadcom (eth1) with the Intel (eth2), but > > they connect at 100Mbps: > > > > # /sbin/mii-tool -v > > mii-tool does not (yet) support more than 100 Mbit/s, so it will report > a 1000 Mbit/s connection as only running 100 Mbit/s. Use ethtool for now. Ouch, you are right. They are really working at 1000Mbit/s. I should have=20 checked that. They work with a crossover cable, but I still have problems w= ith=20 the switch. I'll further investigate before posting again. Thanks! =2D-=20 Alfredo Beaumont. GPG: http://aintel.bi.ehu.es/~jtbbesaa/jtbbesaa.gpg.asc Elektronika eta Telekomunikazioak Saila (Ingeniaritza Telematikoa) Euskal Herriko Unibertsitatea, Bilbao (Basque Country). http://www.ehu.es --nextPart1279143.OyKeIErFOt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCnxOq6KTU/EgLc1ERAsbKAJ9U+j2OiPemLbu1oNp/t/T1ijHWDQCeLRho mxzLFdj20GxHxb4LXD7z5pM= =drCD -----END PGP SIGNATURE----- --nextPart1279143.OyKeIErFOt-- From Peter.Kutschera@arcs.ac.at Thu Jun 2 08:51:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 08:51:41 -0700 (PDT) Received: from s0ms2.arc.local (arcmail.arcs.ac.at [62.218.164.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52FpUXq031245 for ; Thu, 2 Jun 2005 08:51:31 -0700 Received: from s1ms3.D01.arc.local ([172.24.10.15]) by s0ms2.arc.local with Microsoft SMTPSVC(6.0.3790.0); Thu, 2 Jun 2005 17:50:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: R8169 from U.S.Robotics not found by driver Date: Thu, 2 Jun 2005 17:50:28 +0200 Message-ID: <3BDD1137DBC16749ACF2C93F82FCA98DA107D2@s1ms3.D01.arc.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: R8169 from U.S.Robotics not found by driver Thread-Index: AcVnisxe/CbtXBnaRKOcSTb93OxXtg== From: "Kutschera Peter" To: "Linux r8169 crew" X-OriginalArrivalTime: 02 Jun 2005 15:50:28.0291 (UTC) FILETIME=[CC6F2130:01C5678A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j52FpUXq031245 X-archive-position: 1970 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Peter.Kutschera@arcs.ac.at Precedence: bulk X-list: netdev Hello to whoever is out there! I found your e-mail address in r8169.c: MODULE_AUTHOR("Realtek and the Linux r8169 crew "); MODULE_DESCRIPTION("RealTek RTL-8169 Gigabit Ethernet driver"); Maybe you are interested in the following problem? I just bought a new 1000MB NIC from U.S.Robotics since I was thinking there is a driver in kernel 2.6.8. It wasn't. But there is a driver (on the CD and also downloadable from http://www.usr.com/support/product-template.asp?prod=7902 (see linux.exe :-)) And there is also a newer driver in 2.6.11. The different results are: Modprobe r8169 with the driver from 2.6.8 or 2.6.11 simple has no effect - the module is loaded but there is no error message, no eth1 (it's my 2nd network card, eth0 in onboard) and nothing in dmesg :-( I was building and using the driver from U.S.Robotics with 2.6.8 and 2.6.11: pinguc1:~# modprobe r8169 pinguc1:~# dmesg | tail ACPI: PCI interrupt 0000:00:04.0[A] -> GSI 25 (level, low) -> IRQ 193 eth1: Identified chip type is 'RTL8169s/8110s'. eth1: U.S. Robotics 10/100/1000 PCI NIC driver version 2.0 at 0xf89e8000, 00:c0:49:59:28:71, IRQ 193 eth1: Auto-negotiation Enabled. eth1: 1000Mbps Full-duplex operation. pinguc1:~# ifup eth1 pinguc1:~# ping cluster2 PING cluster2 (192.168.1.2) 56(84) bytes of data. 64 bytes from cluster2 (192.168.1.2): icmp_seq=1 ttl=64 time=0.069 ms Fine, isnt' it? NO IT IS NOT :-( It works fine for a wile but when starting to put LOTS OF DATA about this interface: pinguc1:~# dmesg | tail irq 193: nobody cared! [] __report_bad_irq+0x31/0x77 [] note_interrupt+0x4c/0x71 [] __do_IRQ+0xd9/0x121 [] do_IRQ+0x1b/0x28 [] common_interrupt+0x1a/0x20 [] default_idle+0x0/0x29 [] default_idle+0x23/0x29 [] cpu_idle+0x39/0x4e [] start_kernel+0x178/0x17c handlers: [] (rtl8169_interrupt+0x0/0x7e [r8169]) Disabling IRQ #193 No interrupt - No data transfer Maybe some of the following is usefull for you? pinguc1:~# lspci 0000:00:00.0 Host bridge: ServerWorks GCNB-LE Host Bridge (rev 32) 0000:00:00.1 Host bridge: ServerWorks GCNB-LE Host Bridge 0000:00:02.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controlle r (rev 02) 0000:00:04.0 Ethernet controller: U.S. Robotics: Unknown device 0116 (rev 10) 0000:00:0e.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 0000:00:0f.0 Host bridge: ServerWorks CSB5 South Bridge (rev 93) 0000:00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93) 0000:00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 05) 0000:00:0f.3 ISA bridge: ServerWorks CSB5 LPC bridge 0000:00:10.0 Host bridge: ServerWorks CIOB-X2 PCI-X I/O Bridge (rev 05) 0000:00:10.2 Host bridge: ServerWorks CIOB-X2 PCI-X I/O Bridge (rev 05) 0000:01:02.0 RAID bus controller: American Megatrends Inc. MegaRAID (rev 02) 0000:01:04.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fu sion-MPT Dual Ultra320 SCSI (rev 07) pinguc1:~# hd /proc/bus/pci/01/04.0 00000000 00 10 30 00 17 01 30 02 07 00 00 01 10 48 00 00 |..0...0......H..| 00000010 01 dc 00 00 04 00 f1 fc 00 00 00 00 04 00 f0 fc |.Ü....ñü......ðü| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 28 10 35 01 |............(.5.| 00000030 00 00 e0 fc 50 00 00 00 00 00 00 00 0b 01 11 12 |..àüP...........| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 01 58 02 06 00 00 00 00 05 00 80 00 00 00 00 00 |.X..............| 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000100 I am not sure if this is a problem of the USR-hriver or the hardware (Dell PowerEdge 1600). I would like to test your driver but it seems to me that your driver can't find the card. On another PC running the same software (debian sage with 3.6.8 cernel and USR-driver on the other end of the cable) the module from USR seems to work. If you have any tips please let me know. In the meantime i will try another PCI slot and, as iI expect this will not help, an old 3C509. Not the best choice for a linux cluster I think. Thanks Peter -- Dipl.-Ing. Peter Kutschera tel: +43 664 620 7642 http://Peter.Kutschera.at/ mailto:Peter@Kutschera.at From jbenc@suse.cz Thu Jun 2 09:51:37 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 09:51:38 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52GpZXq001174 for ; Thu, 2 Jun 2005 09:51:36 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 38BA662830C; Thu, 2 Jun 2005 18:50:38 +0200 (CEST) Date: Thu, 2 Jun 2005 18:50:38 +0200 From: Jiri Benc To: Gertjan van Wingerde Cc: netdev@oss.sgi.com, jgarzik@pobox.com, jbohac@suse.cz Subject: Re: [PATCH] ieee80211: Update generic definitions to latest specs. Message-ID: <20050602185038.4fd9dafb@griffin.suse.cz> In-Reply-To: <429E1FAB.6080503@home.nl> References: <429E1FAB.6080503@home.nl> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1971 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev On Wed, 01 Jun 2005 22:50:51 +0200, Gertjan van Wingerde wrote: > +#define WLAN_STATUS_ASSOC_DENIED_SPECTRUM_MGMT_REQUIRED 22 > +#define WLAN_STATUS_ASSOC_REJECTED_POWER_CAP_UNACCEPTABLE 23 > +#define WLAN_STATUS_ASSOC_REJECTED_SUPP_CHANNELS_UNACCEPTABLE 24 > (...) > +/* 802.11h */ > +#define WLAN_REASON_DISASSOC_POWER_CAP_UNACCEPTABLE 10 > +#define WLAN_REASON_DISASSOC_SUPP_CHANNELS_UNACCEPTABLE 11 Aren't these identifiers a bit too long? It seems to be unpractical to use them. -- Jiri Benc SUSE Labs From shemminger@osdl.org Thu Jun 2 10:32:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 10:32:39 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52HWRXq003829 for ; Thu, 2 Jun 2005 10:32:27 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j52HUqjA028494 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jun 2005 10:30:53 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j52HUqCQ005577; Thu, 2 Jun 2005 10:30:52 -0700 Date: Thu, 2 Jun 2005 10:30:52 -0700 From: Stephen Hemminger To: hadi@cyberus.ca Cc: Jon Mason , "David S. Miller" , mitch.a.williams@intel.com, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch Message-ID: <20050602103052.66f12f21@dxpl.pdx.osdl.net> In-Reply-To: <1117715207.6050.21.camel@localhost.localdomain> References: <1117241786.6251.7.camel@localhost.localdomain> <200505311707.54487.jdmason@us.ibm.com> <20050531.151443.74564699.davem@davemloft.net> <200505311828.44304.jdmason@us.ibm.com> <1117715207.6050.21.camel@localhost.localdomain> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1972 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 02 Jun 2005 08:26:46 -0400 jamal wrote: > On Tue, 2005-31-05 at 18:28 -0500, Jon Mason wrote: > > On Tuesday 31 May 2005 05:14 pm, David S. Miller wrote: > > > From: Jon Mason > > > Date: Tue, 31 May 2005 17:07:54 -0500 > > > > > > > Of course some performace analysis would have to be done to determine the > > > > optimal numbers for each speed/duplexity setting per driver. > > > > > > per cpu speed, per memory bus speed, per I/O bus speed, and add in other > > > complications such as NUMA > > > > > > My point is that whatever experimental number you come up with will be > > > good for that driver on your systems, not necessarily for others. > > > > > > Even within a system, whatever number you select will be the wrong > > > thing to use if one starts a continuous I/O stream to the SATA > > > controller in the next PCI slot, for example. > > > > > > We keep getting bitten by this, as the Altix perf data continually shows, > > > and we need to absolutely stop thinking this way. > > > > > > The way to go is to make selections based upon observed events and > > > mesaurements. > > > > I'm not arguing against a /proc entry to tune dev->weight for those sysadmins > > advanced enough to do that. I am arguing that we can make the driver smarter > > (at little/no cost) for "out of the box" users. > > > > What is the point of making the driver "smarter"? > Recall, the algorithm used to schedule the netdevices is based on an > extension of Weighted Round Robin from Varghese et al known as DRR (ask > gooogle for details). > The idea is to provide fairness amongst many drivers. As an example, if > you have a gige driver it shouldnt be taking all the resources at the > expense of starving the fastether driver. > If the admin wants one driver to be more "important" than the other, > s/he will make sure it has a higher weight. > In fact, since the default weighting should be based on the amount of cpu time expended per frame rather than link speed. The point is that a more "heavy weight" driver shouldn't starve out all the others. From shemminger@osdl.org Thu Jun 2 10:39:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 10:39:11 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52Hd6Xq004550 for ; Thu, 2 Jun 2005 10:39:06 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j52Hc6jA029209 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jun 2005 10:38:06 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j52Hc5BT006053; Thu, 2 Jun 2005 10:38:05 -0700 Date: Thu, 2 Jun 2005 10:38:05 -0700 From: Stephen Hemminger To: Baruch Even Cc: Adrian Bunk , Andrew Morton , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages Message-ID: <20050602103805.6beb4f4e@dxpl.pdx.osdl.net> In-Reply-To: <429F1079.5070701@ev-en.org> References: <20050601022824.33c8206e.akpm@osdl.org> <20050602121511.GE4992@stusta.de> <429F1079.5070701@ev-en.org> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1973 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 02 Jun 2005 14:58:17 +0100 Baruch Even wrote: > Adrian Bunk wrote: > > On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote: > > > >>... > >>Changes since 2.6.12-rc5-mm1: > >>... > >>+tcp-tcp_infra.patch > >>... > >> Steve Hemminger's TCP enhancements. > >>... > > > > > > I said "no" to CONFIG_TCP_CONG_BIC, and now my syslog is full of messages > > kernel: bic unavailable using TCP reno > > > > I have no problem with such a message being shown once - but once should > > be enough. > > The best solution for this would be to check the available protocols at > setup time and not at connection creation time. This would also provide > a better feedback to the user, since he will either see that what he set > was taken, or it wasn't. > > In the current mechanism you can set the protocol to 'foo' and it will > show back as 'foo'. You'll get complaints only once a connection is > attempted with this protocol. > > It does mean some extra work in the sysctl stage, but it's better IMO to > do it there rather than at connection setup time. > > Baruch Your right, the sysctl handler should be smarter, but that is not the problem here. The problem is that the default value is set to be BIC to be compatible with earlier kernels. Since 75% of the world isn't smart enough to figure out how to use sysctl, there is a question of what the default should be, and what to do if that is missing. One version had a messy ifdef chain to try and avoid the warning: char sysctl_tcp_congestion_control[] = #if defined(CONFIG_TCP_BIC) "bic" #elif defined(CONFIG_TCP_HTCP) "htcp" #else "reno" #endif ; but that was ugly. Another possibility is putting it in as yet another config value at kernel build time. To suppress the warning repeating, probably the best solution would be rewrite the string if we have to revert to reno. But carefully to avoid SMP issues. This also implies a smarter sysctl string handler for this value as well. P.s: saw your comparison paper, after a little more corroboration I would like to make H-TCP the default. From shemminger@osdl.org Thu Jun 2 10:45:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 10:45:34 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52HjRXq005497 for ; Thu, 2 Jun 2005 10:45:27 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j52HiOjA029583 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jun 2005 10:44:25 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j52HiNYe006311; Thu, 2 Jun 2005 10:44:23 -0700 Date: Thu, 2 Jun 2005 10:44:23 -0700 From: Stephen Hemminger To: Cc: , , , Subject: Re: Unable to handle kernel paging request at virtual address 04000460 Message-ID: <20050602104423.2c3825e5@dxpl.pdx.osdl.net> In-Reply-To: <438662DA48DCAA41B1DF648BD4BD76C0E461B8@CHN-SNR-MBX01.wipro.com> References: <438662DA48DCAA41B1DF648BD4BD76C0E461B8@CHN-SNR-MBX01.wipro.com> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1974 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Thu, 2 Jun 2005 09:20:21 +0530 wrote: > Hi David, > I understand that the linux community may not be able to debug it for > me. All I require is if people have seen similar problems (the problems > we face are w.r.t to kfree_skb and skb_drop_fraglist crashing due to > some reason, which could be a Memory Management issue or some thing we > are not aware of), then let us know the patches, so that we can try them > out here. Turn on Debug memory allocations, spinlock debugging, sleep-inside-spinlock checking, and preempt, it will help your debugging. If you are not building your own kernel from source learn how. You are probably freeing memory twice, or not doing ref counting properly or other locking issues. Since it is your code, good luck debugging it, if you want the community help it needs to be open source code that is available for download or be in the kernel.org kernel. From shemminger@osdl.org Thu Jun 2 10:53:39 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 10:53:44 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52HrcXq006428 for ; Thu, 2 Jun 2005 10:53:38 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j52HqcjA030322 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jun 2005 10:52:39 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j52HqcMY006729; Thu, 2 Jun 2005 10:52:38 -0700 Date: Thu, 2 Jun 2005 10:52:38 -0700 From: Stephen Hemminger To: Andrew Morton Cc: John Heffner , netdev@oss.sgi.com Subject: [PATCH] Scalable TCP (cleaned) Message-ID: <20050602105238.69b6bcb3@dxpl.pdx.osdl.net> In-Reply-To: <200505251550.42252.jheffner@psc.edu> References: <200505251550.42252.jheffner@psc.edu> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1975 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Here is a whitespace cleaned up version of John's scaleable TCP patch to go with the other TCP congestion algorithms, to put in -mm. -------- This patch implements Tom Kelly's Scalable TCP congestion control algorithm for the modular framework. The algorithm has some nice scaling properties, and has been used a fair bit in research, though is known to have significant fairness issues, so it's not really suitable for general purpose use. Signed-off-by: John Heffner Index: 2.6.12-rc5-tcp3/net/ipv4/Makefile =================================================================== --- 2.6.12-rc5-tcp3.orig/net/ipv4/Makefile +++ 2.6.12-rc5-tcp3/net/ipv4/Makefile @@ -35,6 +35,7 @@ obj-$(CONFIG_TCP_CONG_HSTCP) += tcp_high obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybla.o obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o +obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o Index: 2.6.12-rc5-tcp3/net/ipv4/tcp_scalable.c =================================================================== --- /dev/null +++ 2.6.12-rc5-tcp3/net/ipv4/tcp_scalable.c @@ -0,0 +1,68 @@ +/* Tom Kelly's Scalable TCP + * + * See htt://www-lce.eng.cam.ac.uk/~ctk21/scalable/ + * + * John Heffner + */ + +#include +#include +#include + +/* These factors derived from the recommended values in the paper: + * .01 and and 7/8. We use 50 instead of 100 to account for + * delayed ack. + */ +#define TCP_SCALABLE_AI_CNT 50U +#define TCP_SCALABLE_MD_SCALE 3 + +static void tcp_scalable_cong_avoid(struct tcp_sock *tp, u32 ack, u32 rtt, + u32 in_flight, int flag) +{ + if (in_flight < tp->snd_cwnd) + return; + + if (tp->snd_cwnd <= tp->snd_ssthresh) { + tp->snd_cwnd++; + } else { + tp->snd_cwnd_cnt++; + if (tp->snd_cwnd_cnt > min(tp->snd_cwnd, TCP_SCALABLE_AI_CNT)){ + tp->snd_cwnd++; + tp->snd_cwnd_cnt = 0; + } + } + tp->snd_cwnd = min_t(u32, tp->snd_cwnd, tp->snd_cwnd_clamp); + tp->snd_cwnd_stamp = tcp_time_stamp; +} + +static u32 tcp_scalable_ssthresh(struct tcp_sock *tp) +{ + return max(tp->snd_cwnd - (tp->snd_cwnd>>TCP_SCALABLE_MD_SCALE), 2U); +} + + +static struct tcp_congestion_ops tcp_scalable = { + .ssthresh = tcp_scalable_ssthresh, + .cong_avoid = tcp_scalable_cong_avoid, + .min_cwnd = tcp_reno_min_cwnd, + + .owner = THIS_MODULE, + .name = "scalable", +}; + +static int __init tcp_scalable_register(void) +{ + return tcp_register_congestion_control(&tcp_scalable); +} + +static void __exit tcp_scalable_unregister(void) +{ + tcp_unregister_congestion_control(&tcp_scalable); +} + +module_init(tcp_scalable_register); +module_exit(tcp_scalable_unregister); + +MODULE_AUTHOR("John Heffner"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("Scalable TCP"); Index: 2.6.12-rc5-tcp3/net/ipv4/Kconfig =================================================================== --- 2.6.12-rc5-tcp3.orig/net/ipv4/Kconfig +++ 2.6.12-rc5-tcp3/net/ipv4/Kconfig @@ -481,6 +481,15 @@ config TCP_CONG_VEGAS window. TCP Vegas should provide less packet loss, but it is not as aggressive as TCP Reno. +config TCP_CONG_SCALABLE + tristate "Scalable TCP" + depends on EXPERIMENTAL + default n + ---help--- + Scalable TCP is a sender-side only change to TCP which uses a + MIMD congestion control algorithm which has some nice scaling + properties, though is known to have fairness issues. + See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/ endmenu From shemminger@osdl.org Thu Jun 2 11:15:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 11:15:47 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52IFgXq008328 for ; Thu, 2 Jun 2005 11:15:43 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j52IEbjA000394 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jun 2005 11:14:38 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j52IEbtP008613; Thu, 2 Jun 2005 11:14:37 -0700 Date: Thu, 2 Jun 2005 11:14:37 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Mitch Williams , netdev@oss.sgi.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: [PATCH] net: allow controlling NAPI weight with sysfs Message-ID: <20050602111437.1c492138@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1976 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Simple interface to allow changing network device scheduling weight with sysfs. Please consider this for 2.6.12, since risk/impact is small. Signed-off-by: Stephen Hemminger Index: napi-sysfs/net/core/net-sysfs.c =================================================================== --- napi-sysfs.orig/net/core/net-sysfs.c +++ napi-sysfs/net/core/net-sysfs.c @@ -184,6 +184,22 @@ static ssize_t store_tx_queue_len(struct static CLASS_DEVICE_ATTR(tx_queue_len, S_IRUGO | S_IWUSR, show_tx_queue_len, store_tx_queue_len); +NETDEVICE_SHOW(weight, fmt_ulong); + +static int change_weight(struct net_device *net, unsigned long new_weight) +{ + net->weight = new_weight; + return 0; +} + +static ssize_t store_weight(struct class_device *dev, const char *buf, size_t len) +{ + return netdev_store(dev, buf, len, change_weight); +} + +static CLASS_DEVICE_ATTR(weight, S_IRUGO | S_IWUSR, show_weight, + store_weight); + static struct class_device_attribute *net_class_attributes[] = { &class_device_attr_ifindex, @@ -193,6 +209,7 @@ static struct class_device_attribute *ne &class_device_attr_features, &class_device_attr_mtu, &class_device_attr_flags, + &class_device_attr_weight, &class_device_attr_type, &class_device_attr_address, &class_device_attr_broadcast, From shemminger@osdl.org Thu Jun 2 11:20:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 11:20:13 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52IKAXq008963 for ; Thu, 2 Jun 2005 11:20:10 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j52IJ9jA001475 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jun 2005 11:19:10 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j52IJ97X009167; Thu, 2 Jun 2005 11:19:09 -0700 Date: Thu, 2 Jun 2005 11:19:09 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: Mitch Williams , netdev@oss.sgi.com Subject: [PATCH] net: fix sysctl_ Message-ID: <20050602111909.63ef419a@dxpl.pdx.osdl.net> In-Reply-To: References: Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1977 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Changing the sysctl net.core.dev_weight has no effect because the weight of the backlog devices is set during initialization and never changed. This patch propagates any changes to the global value affected by sysctl to the per-cpu devices. It is done every time the packet handler function is run. Signed-off-by: Stephen Hemminger Index: skge-0.8/net/core/dev.c =================================================================== --- skge-0.8.orig/net/core/dev.c +++ skge-0.8/net/core/dev.c @@ -1732,6 +1732,7 @@ static int process_backlog(struct net_de struct softnet_data *queue = &__get_cpu_var(softnet_data); unsigned long start_time = jiffies; + backlog_dev->weight = weight_p; for (;;) { struct sk_buff *skb; struct net_device *dev; From romieu@fr.zoreil.com Thu Jun 2 11:36:06 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 11:36:10 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52Ia4Xq010316 for ; Thu, 2 Jun 2005 11:36:05 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.1/8.12.1) with ESMTP id j52IZ24i006169; Thu, 2 Jun 2005 20:35:02 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.1/8.13.1/Submit) id j52IYuZT006168; Thu, 2 Jun 2005 20:34:56 +0200 Date: Thu, 2 Jun 2005 20:34:56 +0200 From: Francois Romieu To: Kutschera Peter Cc: Linux r8169 crew , jgarzik@pobox.com Subject: Re: R8169 from U.S.Robotics not found by driver Message-ID: <20050602183456.GA5606@electric-eye.fr.zoreil.com> References: <3BDD1137DBC16749ACF2C93F82FCA98DA107D2@s1ms3.D01.arc.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BDD1137DBC16749ACF2C93F82FCA98DA107D2@s1ms3.D01.arc.local> User-Agent: Mutt/1.4.1i X-Organisation: Land of Sunshine Inc. X-Subliminal-Message: Merge the r8169 driver in mainline X-archive-position: 1978 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Kutschera Peter : [...] > If you have any tips please let me know. Upgrade to (at your option): - 2.6.12-rc5 + Jeff Garzik's r8169 git branch; - 2.6.12-rc5-mm2. Both contain the latest r8169 driver. It will handle USR hardware. If you manage to kill it, please report it. Would your setup allow to test the driver in the Mpps range by any luck ? -- Ueimor From gwingerde@home.nl Thu Jun 2 12:03:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 12:03:29 -0700 (PDT) Received: from smtpq3.home.nl (smtpq3.home.nl [213.51.128.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52J3QXq012315 for ; Thu, 2 Jun 2005 12:03:27 -0700 Message-Id: <200506021903.j52J3QXq012315@oss.sgi.com> Received: from [213.51.128.134] (port=56855 helo=smtp3.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1DduxW-0005WB-6W; Thu, 02 Jun 2005 21:02:26 +0200 Received: from [10.100.3.12] (port=33042 helo=mail.home.nl) by smtp3.home.nl with smtp (Exim 4.30) id 1DduxU-00011G-VC; Thu, 02 Jun 2005 21:02:24 +0200 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) X-Originating-IP: [213.84.184.98] From: To: Jiri Benc CC: , , Subject: Antw: Re: [PATCH] ieee80211: Update generic definitions to latest specs. Date: Thu, 2 Jun 2005 21:02:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean X-archive-position: 1979 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gwingerde@home.nl Precedence: bulk X-list: netdev Content-Length: 724 Lines: 22 On Thu, 02 Jun 2005, Jiri Benc wrote: > On Wed, 01 Jun 2005 22:50:51 +0200, Gertjan van Wingerde wrote: > > +#define WLAN_STATUS_ASSOC_DENIED_SPECTRUM_MGMT_REQUIRED 22 > > +#define WLAN_STATUS_ASSOC_REJECTED_POWER_CAP_UNACCEPTABLE 23 > > +#define WLAN_STATUS_ASSOC_REJECTED_SUPP_CHANNELS_UNACCEPTABLE 24 > > (...) > > +/* 802.11h */ > > +#define WLAN_REASON_DISASSOC_POWER_CAP_UNACCEPTABLE 10 > > +#define WLAN_REASON_DISASSOC_SUPP_CHANNELS_UNACCEPTABLE 11 > > Aren't these identifiers a bit too long? It seems to be unpractical to use > them. > I was thinking about that too, but couldn't find a proper shorter version without losing the descriptive meaning. Do you have any suggestions to shorten them? BR, Gertjan From davem@davemloft.net Thu Jun 2 13:07:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 13:07:58 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52K7sXq019659 for ; Thu, 2 Jun 2005 13:07:54 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Ddvxo-0001uE-Nv; Thu, 02 Jun 2005 13:06:48 -0700 Date: Thu, 02 Jun 2005 13:06:48 -0700 (PDT) Message-Id: <20050602.130648.75428139.davem@davemloft.net> To: bunk@stusta.de Cc: akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org Subject: Re: [2.6 patch] net/ipv6/ipv6_syms.c: unexport fl6_sock_lookup From: "David S. Miller" In-Reply-To: <20050530205653.GZ10441@stusta.de> References: <20050530205653.GZ10441@stusta.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 254 Lines: 9 From: Adrian Bunk Date: Mon, 30 May 2005 22:56:53 +0200 > There is no usage of this EXPORT_SYMBOL in the kernel. > > Signed-off-by: Adrian Bunk > Acked-by: Hideaki YOSHIFUJI Applied, thanks. From davem@davemloft.net Thu Jun 2 13:03:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 13:03:51 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52K3lXq019130 for ; Thu, 2 Jun 2005 13:03:47 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Ddvth-0001s9-Sa; Thu, 02 Jun 2005 13:02:33 -0700 Date: Thu, 02 Jun 2005 13:02:33 -0700 (PDT) Message-Id: <20050602.130233.59653068.davem@davemloft.net> To: bunk@stusta.de Cc: ja@ssi.bg, wensong@LinuxVirtualServer.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] remove net/ipv4/ipvs/ip_vs_proto_icmp.c? From: "David S. Miller" In-Reply-To: <20050515132906.GW16549@stusta.de> References: <20050513041622.GE3603@stusta.de> <20050515132906.GW16549@stusta.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1980 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 189 Lines: 8 From: Adrian Bunk Date: Sun, 15 May 2005 15:29:06 +0200 > ip_vs_proto_icmp.c was never finished. > > Signed-off-by: Adrian Bunk Applied, thanks Adrian. From bunk@stusta.de Thu Jun 2 13:08:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 13:08:13 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j52K81Xq019698 for ; Thu, 2 Jun 2005 13:08:02 -0700 Received: (qmail 32434 invoked from network); 2 Jun 2005 20:07:04 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 2 Jun 2005 20:07:04 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 67F5ABBFA9; Thu, 2 Jun 2005 22:07:02 +0200 (CEST) Date: Thu, 2 Jun 2005 22:07:02 +0200 From: Adrian Bunk To: Andrew Morton , jkmaline@cc.hut.fi, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org, hostap@shmoo.com, netdev@oss.sgi.com Subject: [-mm patch] fix recursive IPW2200 dependencies Message-ID: <20050602200701.GG4992@stusta.de> References: <20050601022824.33c8206e.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050601022824.33c8206e.akpm@osdl.org> User-Agent: Mutt/1.5.9i X-archive-position: 1982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 999 Lines: 34 On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote: >... > Changes since 2.6.12-rc5-mm1: >... > +git-netdev-we18-ieee80211-wifi.patch > > Various things added and merged in netdev land. >... This results in recursive dependencies: - IPW2200 depends on NET_RADIO - IPW2200 selects IEEE80211 - IEEE80211 selects NET_RADIO This patch fixes the IPW2200 dependencies in a way that they are similar to the IPW2100 dependencies. Signed-off-by: Adrian Bunk --- linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig.old 2005-06-02 22:04:02.000000000 +0200 +++ linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig 2005-06-02 22:04:40.000000000 +0200 @@ -192,9 +192,8 @@ config IPW2200 tristate "Intel PRO/Wireless 2200BG and 2915ABG Network Connection" - depends on NET_RADIO && PCI + depends on IEEE80211 && PCI select FW_LOADER - select IEEE80211 ---help--- A driver for the Intel PRO/Wireless 2200BG and 2915ABG Network Connection adapters. From davem@davemloft.net Thu Jun 2 13:14:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 13:14:22 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52KEJXq021078 for ; Thu, 2 Jun 2005 13:14:20 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Ddw42-0001wh-Vk; Thu, 02 Jun 2005 13:13:15 -0700 Date: Thu, 02 Jun 2005 13:13:14 -0700 (PDT) Message-Id: <20050602.131314.21926883.davem@davemloft.net> To: bunk@stusta.de Cc: akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [RFC: 2.6 patch] net/ipv4/: possible cleanups From: "David S. Miller" In-Reply-To: <20050530205651.GY10441@stusta.de> References: <20050530205651.GY10441@stusta.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 955 Lines: 28 From: Adrian Bunk Subject: [RFC: 2.6 patch] net/ipv4/: possible cleanups Date: Mon, 30 May 2005 22:56:51 +0200 > This patch contains the following possible cleanups: > - make needlessly global code static > - #if 0 the following unused global function: > - xfrm4_state.c: xfrm4_state_fini > - remove the following unneeded EXPORT_SYMBOL's: > - ip_output.c: ip_finish_output > - ip_output.c: sysctl_ip_default_ttl > - fib_frontend.c: ip_dev_find > - inetpeer.c: inet_peer_idlock > - ip_options.c: ip_options_compile > - ip_options.c: ip_options_undo > - tcp_ipv4.c: sysctl_max_syn_backlog > > Please review which of these changes are correct and which might > conflict with pending patches. Please keep all of the ECN implementation in the tcp_ecn.h header file, even if the routine is only called in one C file. And therefore, please do not remove the tcp_enter_quickack_mode() extern declaration from tcp.h Thanks. From davem@davemloft.net Thu Jun 2 13:15:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 13:15:35 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52KFWXq021474 for ; Thu, 2 Jun 2005 13:15:32 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Ddw5E-0001xY-Nx; Thu, 02 Jun 2005 13:14:28 -0700 Date: Thu, 02 Jun 2005 13:14:28 -0700 (PDT) Message-Id: <20050602.131428.28787855.davem@davemloft.net> To: bunk@stusta.de Cc: akpm@osdl.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [2.6 patch] net/socket.c: unexport move_addr_to_kernel From: "David S. Miller" In-Reply-To: <20050530205647.GW10441@stusta.de> References: <20050530205647.GW10441@stusta.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1984 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 329 Lines: 10 From: Adrian Bunk Date: Mon, 30 May 2005 22:56:47 +0200 > I didn't find any modular usage in the kernel. > > Signed-off-by: Adrian Bunk Yes, but as a part of the socket kernel API, I could definitely see some out-of-tree code legitimately using this interface. Let's keep it around for now. From abonilla@linuxwireless.org Thu Jun 2 13:20:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 13:20:19 -0700 (PDT) Received: from linuxwireless.org.ve.carpathiahost.net (linuxwireless.org.ve.carpathiahost.net [66.117.45.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52KKEXq022260 for ; Thu, 2 Jun 2005 13:20:15 -0700 Received: from WCRSJO2KPAB047 ([200.9.49.66]) by linuxwireless.org.ve.carpathiahost.net (8.12.10/8.12.10) with SMTP id j52KJEnE002565; Thu, 2 Jun 2005 16:19:14 -0400 Reply-To: From: "Alejandro Bonilla" To: "'Adrian Bunk'" , "'Andrew Morton'" , , Cc: , , Subject: RE: [-mm patch] fix recursive IPW2200 dependencies Date: Thu, 2 Jun 2005 14:19:10 -0600 Message-ID: <003a01c567b0$56bed860$600cc60a@amer.sykes.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20050602200701.GG4992@stusta.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-archive-position: 1985 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: abonilla@linuxwireless.org Precedence: bulk X-list: netdev Content-Length: 1333 Lines: 49 > On Wed, Jun 01, 2005 at 02:28:24AM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.12-rc5-mm1: > >... > > +git-netdev-we18-ieee80211-wifi.patch > > > > Various things added and merged in netdev land. > >... > > This results in recursive dependencies: > - IPW2200 depends on NET_RADIO > - IPW2200 selects IEEE80211 > - IEEE80211 selects NET_RADIO > > > This patch fixes the IPW2200 dependencies in a way that they > are similar > to the IPW2100 dependencies. > > Signed-off-by: Adrian Bunk > > --- > linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig.old > 2005-06-02 22:04:02.000000000 +0200 > +++ linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig > 2005-06-02 22:04:40.000000000 +0200 > @@ -192,9 +192,8 @@ > > config IPW2200 > tristate "Intel PRO/Wireless 2200BG and 2915ABG Network > Connection" > - depends on NET_RADIO && PCI > + depends on IEEE80211 && PCI > select FW_LOADER > - select IEEE80211 > ---help--- > A driver for the Intel PRO/Wireless 2200BG and > 2915ABG Network > Connection adapters. I think the normal usage of the name is Intel PRO/Wireless 2200BG/2915ABG Network Connection. I'm just saying this in case that you care about Intel Trademarking or about a more unified usage of the name of the Adapter. maybe this is something silly. .Alejandro From bunk@stusta.de Thu Jun 2 13:39:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 13:39:28 -0700 (PDT) Received: from mailout.stusta.mhn.de (emailhub.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j52KdMXq023360 for ; Thu, 2 Jun 2005 13:39:23 -0700 Received: (qmail 922 invoked from network); 2 Jun 2005 20:38:25 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailhub.stusta.mhn.de with SMTP; 2 Jun 2005 20:38:25 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id 942E4AFA78; Thu, 2 Jun 2005 22:38:23 +0200 (CEST) Date: Thu, 2 Jun 2005 22:38:23 +0200 From: Adrian Bunk To: Stephen Hemminger Cc: Baruch Even , Andrew Morton , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.12-rc5-mm2: "bic unavailable using TCP reno" messages Message-ID: <20050602203823.GI4992@stusta.de> References: <20050601022824.33c8206e.akpm@osdl.org> <20050602121511.GE4992@stusta.de> <429F1079.5070701@ev-en.org> <20050602103805.6beb4f4e@dxpl.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050602103805.6beb4f4e@dxpl.pdx.osdl.net> User-Agent: Mutt/1.5.9i X-archive-position: 1986 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: netdev Content-Length: 1619 Lines: 56 On Thu, Jun 02, 2005 at 10:38:05AM -0700, Stephen Hemminger wrote: > On Thu, 02 Jun 2005 14:58:17 +0100 > Baruch Even wrote: > > >... > > Your right, the sysctl handler should be smarter, but that is not the problem here. > The problem is that the default value is set to be BIC to be compatible with earlier kernels. > Since 75% of the world isn't smart enough to figure out how to use sysctl, there is a > question of what the default should be, and what to do if that is missing. > > One version had a messy ifdef chain to try and avoid the warning: > > char sysctl_tcp_congestion_control[] = > #if defined(CONFIG_TCP_BIC) > "bic" > #elif defined(CONFIG_TCP_HTCP) > "htcp" > #else > "reno" > #endif > ; > > but that was ugly. > > Another possibility is putting it in as yet another config value at kernel build time. >... One thing that currently makes all solutions harder (and the #ifdef example above not ugly but simply wrong) is that you allow modular congestion control options for the always static net support. Is this really required? The IO schedulers have a similar problem, and they are using the #ifdef approach for selecting the default. One approach is to actually choose the default using #ifdef's. You could also do any kind of runtime selection, but please don't print the warning more than once. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed From mchan@broadcom.com Thu Jun 2 13:55:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 13:55:44 -0700 (PDT) Received: from MMS1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52KtfXq024547 for ; Thu, 2 Jun 2005 13:55:41 -0700 Received: from 10.10.64.121 by MMS1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 02 Jun 2005 13:54:34 -0700 X-Server-Uuid: 146C3151-C1DE-4F71-9D02-C3BE503878DD Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 2 Jun 2005 13:54:32 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BBU46339; Thu, 2 Jun 2005 13:54:28 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id NAA08432; Thu, 2 Jun 2005 13:54:28 -0700 (PDT) Received: from 10.7.18.177 ([10.7.18.177]) by NT-IRVA-0741.brcm.ad.broadcom.com ([10.8.194.54]) with Microsoft Exchange Server HTTP-DAV ; Thu, 2 Jun 2005 20:54:27 +0000 Received: from rh4 by nt-irva-0741; 02 Jun 2005 12:56:53 -0700 Subject: Re: Locking model for NAPI drivers From: "Michael Chan" To: "David S. Miller" cc: netdev@oss.sgi.com In-Reply-To: <1117661650.4310.62.camel@rh4> References: <20050531.154847.63995530.davem@davemloft.net> <1117658019.4310.58.camel@rh4> <20050601.152134.120445266.davem@davemloft.net> <1117661650.4310.62.camel@rh4> Date: Thu, 02 Jun 2005 12:56:52 -0700 Message-ID: <1117742212.22670.24.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-WSS-ID: 6E81AD802U44899064-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 1987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 1057 Lines: 27 On Wed, 2005-06-01 at 14:34 -0700, Michael Chan wrote: > On Wed, 2005-06-01 at 15:21 -0700, David S. Miller wrote: > > Since the caller shuts down NAPI ->poll(), after setting the SYNC bit > > we can just check the MAILBOX register, and if a '1' is there just > > return. Does one need to mask out the upper bits of the regiser in > > order to avoid seeing the IRQ tag in such a comparison? > > > No, just check for the value 1 since that's the value we use to disable > interrupts. The value read back will always be 1 if 1 was previously > written to it. > One more race condition: CPU1 CPU2 tg3_poll() __netif_rx_complete() tg3_netif_stop() netif_poll_disable() tg3_full_lock() tg3_irq_quiesce() tg3_restart_ints() BUG_ON(tp->irq_state) This race condition is somewhat harmless but I think we need to take care of it for correctness. Any simple ways to fix it? From john.ronciak@intel.com Thu Jun 2 14:22:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 14:22:46 -0700 (PDT) Received: from orsfmr004.jf.intel.com (fmr19.intel.com [134.134.136.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52LMRXq026133 for ; Thu, 2 Jun 2005 14:22:27 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j52LK7HM032086; Thu, 2 Jun 2005 21:20:07 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j52LK5go030673; Thu, 2 Jun 2005 21:20:05 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005060214200507391 ; Thu, 02 Jun 2005 14:20:05 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 14:19:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC: NAPI packet weighting patch Date: Thu, 2 Jun 2005 14:19:55 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: NAPI packet weighting patch Thread-Index: AcVnbmGZxxYUID7BQ5qgE6xlxM/aIwASbefA From: "Ronciak, John" To: , "Jon Mason" Cc: "David S. Miller" , "Williams, Mitch A" , , , , "Venkatesan, Ganesh" , "Brandeburg, Jesse" X-OriginalArrivalTime: 02 Jun 2005 21:19:56.0276 (UTC) FILETIME=[D3124340:01C567B8] X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j52LMRXq026133 X-archive-position: 1988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: john.ronciak@intel.com Precedence: bulk X-list: netdev Content-Length: 4140 Lines: 100 The DRR algorithm assumes a perfect world, where hardware resources are infinite, packets arrive continuously (or separated by very long delays), there are no bus latencies, and CPU speed is infinite. The real world is much messier: hardware starves for resources if it's not serviced quickly enough, packets arrive at inconvenient intervals (especially at 10 and 100 Mbps speeds), and buses and CPUs are slow. Thus, the driver should have the intelligence built into it to make an "intelligent" choice on what the weight should be for that driver/hardware. The calculation in the driver should take into account all the factors that the driver has access to. These include link speed, bus type and speed, processor speed and some amount of actual device FIFO size and latency smarts. The driver would use all of the factors to come up with a weight to prevent it from dropping frames and not to starve out other devices in the system or hinder performance. It seems to us that the driver is the one that know best and should try to come up with a reasonable value for weight based on its own knowledge of the hardware. This has been showing up in our NAPI test data which Mitch is currently scrubbing for release. It shows that there is a need for either better default static weight numbers or for them to be calculated based on some system dynamic variables. We would like to see the latter tried but the only problem is that each driver would have to make its own calculations, and it may not have access to all of the system-wide data it would need to make a proper calculation. Even with a more intelligent driver, we still would like to see some mechanism for the weight to be changed at runtime, such as with Stephen's sysfs patch. This would allow a sysadmin (or user-space app) to tune the system based on statistical data that isn't available to the individual driver. Cheers, John > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Thursday, June 02, 2005 5:27 AM > To: Jon Mason > Cc: David S. Miller; Williams, Mitch A; shemminger@osdl.org; > netdev@oss.sgi.com; Robert.Olsson@data.slu.se; Ronciak, John; > Venkatesan, Ganesh; Brandeburg, Jesse > Subject: Re: RFC: NAPI packet weighting patch > > > On Tue, 2005-31-05 at 18:28 -0500, Jon Mason wrote: > > On Tuesday 31 May 2005 05:14 pm, David S. Miller wrote: > > > From: Jon Mason > > > Date: Tue, 31 May 2005 17:07:54 -0500 > > > > > > > Of course some performace analysis would have to be > done to determine the > > > > optimal numbers for each speed/duplexity setting per driver. > > > > > > per cpu speed, per memory bus speed, per I/O bus speed, > and add in other > > > complications such as NUMA > > > > > > My point is that whatever experimental number you come up > with will be > > > good for that driver on your systems, not necessarily for others. > > > > > > Even within a system, whatever number you select will be the wrong > > > thing to use if one starts a continuous I/O stream to the SATA > > > controller in the next PCI slot, for example. > > > > > > We keep getting bitten by this, as the Altix perf data > continually shows, > > > and we need to absolutely stop thinking this way. > > > > > > The way to go is to make selections based upon observed events and > > > mesaurements. > > > > I'm not arguing against a /proc entry to tune dev->weight > for those sysadmins > > advanced enough to do that. I am arguing that we can make > the driver smarter > > (at little/no cost) for "out of the box" users. > > > > What is the point of making the driver "smarter"? > Recall, the algorithm used to schedule the netdevices is based on an > extension of Weighted Round Robin from Varghese et al known > as DRR (ask > gooogle for details). > The idea is to provide fairness amongst many drivers. As an > example, if > you have a gige driver it shouldnt be taking all the resources at the > expense of starving the fastether driver. > If the admin wants one driver to be more "important" than the other, > s/he will make sure it has a higher weight. > > cheers, > jamal > > From shemminger@osdl.org Thu Jun 2 14:33:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 14:33:14 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52LX1Xq027235 for ; Thu, 2 Jun 2005 14:33:01 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j52LVQjA018683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jun 2005 14:31:26 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j52LVQL9019198; Thu, 2 Jun 2005 14:31:26 -0700 Date: Thu, 2 Jun 2005 14:31:26 -0700 From: Stephen Hemminger To: "Ronciak, John" Cc: , "Jon Mason" , "David S. Miller" , "Williams, Mitch A" , , , "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch Message-ID: <20050602143126.7c302cfd@dxpl.pdx.osdl.net> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2869 Lines: 57 On Thu, 2 Jun 2005 14:19:55 -0700 "Ronciak, John" wrote: > The DRR algorithm assumes a perfect world, where hardware resources are > infinite, packets arrive continuously (or separated by very long > delays), there are no bus latencies, and CPU speed is infinite. > > The real world is much messier: hardware starves for resources if it's > not serviced quickly enough, packets arrive at inconvenient intervals > (especially at 10 and 100 Mbps speeds), and buses and CPUs are slow. > > Thus, the driver should have the intelligence built into it to make an > "intelligent" choice on what the weight should be for that > driver/hardware. The calculation in the driver should take into account > all the factors that the driver has access to. These include link > speed, bus type and speed, processor speed and some amount of actual > device FIFO size and latency smarts. The driver would use all of the > factors to come up with a weight to prevent it from dropping frames and > not to starve out other devices in the system or hinder performance. It > seems to us that the driver is the one that know best and should try to > come up with a reasonable value for weight based on its own knowledge of > the hardware. This is like saying each CPU vendor should write their own process scheduler for Linux. Now with NUMA and HT, it is getting almost that bad but we still try and keep it CPU neutral. For networking the problem is worse, the "right" choice depends on workload and relationship between components in the system. I can't see how you could ever expect a driver specific solution. > This has been showing up in our NAPI test data which Mitch is currently > scrubbing for release. It shows that there is a need for either better > default static weight numbers or for them to be calculated based on some > system dynamic variables. We would like to see the latter tried but the > only problem is that each driver would have to make its own > calculations, and it may not have access to all of the system-wide data > it would need to make a proper calculation. And for other workloads, and other systems (think about the Altix with long access latencies), your numbers will be wrong. Perhaps we need to quit trying for a perfect solution and just get a "good enough" one that works. Let's keep the intelligence out of the driver. Most of the existing smart drivers end up looking like crap and don't work that well. > Even with a more intelligent driver, we still would like to see some > mechanism for the weight to be changed at runtime, such as with > Stephen's sysfs patch. This would allow a sysadmin (or user-space app) > to tune the system based on statistical data that isn't available to the > individual driver. > It will be yet another knob that all except the benchmark tweakers can ignore (hopefully). From mmporter@cox.net Thu Jun 2 14:35:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 14:35:08 -0700 (PDT) Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52LZ2Xq028054 for ; Thu, 2 Jun 2005 14:35:03 -0700 Received: from liberty.homelinux.org ([68.2.41.86]) by fed1rmmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050602213405.WKPG19494.fed1rmmtao06.cox.net@liberty.homelinux.org>; Thu, 2 Jun 2005 17:34:05 -0400 Received: (from mmporter@localhost) by liberty.homelinux.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA26210; Thu, 2 Jun 2005 14:34:04 -0700 Date: Thu, 2 Jun 2005 14:34:04 -0700 From: Matt Porter To: torvalds@osdl.org, akpm@osdl.org, jgarzik@pobox.com Cc: linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org, netdev@oss.sgi.com Subject: [PATCH][5/5] RapidIO support: net driver over messaging Message-ID: <20050602143404.F24818@cox.net> References: <20050602140359.B24818@cox.net> <20050602141247.C24818@cox.net> <20050602141946.D24818@cox.net> <20050602142509.E24818@cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050602142509.E24818@cox.net>; from mporter@kernel.crashing.org on Thu, Jun 02, 2005 at 02:25:10PM -0700 X-archive-position: 1990 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mporter@kernel.crashing.org Precedence: bulk X-list: netdev Content-Length: 17633 Lines: 670 Adds an "Ethernet" driver which sends Ethernet packets over the standard RapidIO messaging. This depends on the core RIO patch for mailbox/doorbell access. Signed-off-by: Matt Porter Index: drivers/net/Kconfig =================================================================== --- 711ec47634f5d5ded866eaa965a0f7dadcbc65f4/drivers/net/Kconfig (mode:100644) +++ 8bdd37ff79724c95795ed39c28588a94e1f13e60/drivers/net/Kconfig (mode:100644) @@ -2185,6 +2185,20 @@ tristate "iSeries Virtual Ethernet driver support" depends on NETDEVICES && PPC_ISERIES +config RIONET + tristate "RapidIO Ethernet over messaging driver support" + depends on NETDEVICES && RAPIDIO + +config RIONET_TX_SIZE + int "Number of outbound queue entries" + depends on RIONET + default "128" + +config RIONET_RX_SIZE + int "Number of inbound queue entries" + depends on RIONET + default "128" + config FDDI bool "FDDI driver support" depends on NETDEVICES && (PCI || EISA) Index: drivers/net/Makefile =================================================================== --- 711ec47634f5d5ded866eaa965a0f7dadcbc65f4/drivers/net/Makefile (mode:100644) +++ 8bdd37ff79724c95795ed39c28588a94e1f13e60/drivers/net/Makefile (mode:100644) @@ -58,6 +58,7 @@ obj-$(CONFIG_VIA_RHINE) += via-rhine.o obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o +obj-$(CONFIG_RIONET) += rionet.o # # end link order section Index: drivers/net/rionet.c =================================================================== --- /dev/null (tree:711ec47634f5d5ded866eaa965a0f7dadcbc65f4) +++ 8bdd37ff79724c95795ed39c28588a94e1f13e60/drivers/net/rionet.c (mode:100644) @@ -0,0 +1,622 @@ +/* + * rionet - Ethernet driver over RapidIO messaging services + * + * Copyright 2005 MontaVista Software, Inc. + * Matt Porter + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#define DRV_NAME "rionet" +#define DRV_VERSION "0.1" +#define DRV_AUTHOR "Matt Porter " +#define DRV_DESC "Ethernet over RapidIO" + +MODULE_AUTHOR(DRV_AUTHOR); +MODULE_DESCRIPTION(DRV_DESC); +MODULE_LICENSE("GPL"); + +#define RIONET_DEFAULT_MSGLEVEL 0 +#define RIONET_DOORBELL_JOIN 0x1000 +#define RIONET_DOORBELL_LEAVE 0x1001 + +#define RIONET_MAILBOX 0 + +#define RIONET_TX_RING_SIZE CONFIG_RIONET_TX_SIZE +#define RIONET_RX_RING_SIZE CONFIG_RIONET_RX_SIZE + +LIST_HEAD(rionet_peers); + +struct rionet_private { + struct rio_mport *mport; + struct sk_buff *rx_skb[RIONET_RX_RING_SIZE]; + struct sk_buff *tx_skb[RIONET_TX_RING_SIZE]; + struct net_device_stats stats; + int rx_slot; + int tx_slot; + int tx_cnt; + int ack_slot; + spinlock_t lock; + u32 msg_enable; +}; + +struct rionet_peer { + struct list_head node; + struct rio_dev *rdev; + struct resource *res; +}; + +static int rionet_check = 0; +static int rionet_capable = 1; +static struct net_device *sndev = NULL; + +/* + * This is a fast lookup table for for translating TX + * Ethernet packets into a destination RIO device. It + * could be made into a hash table to save memory depending + * on system trade-offs. + */ +static struct rio_dev *rionet_active[RIO_MAX_ROUTE_ENTRIES]; + +#define is_rionet_capable(pef, src_ops, dst_ops) \ + ((pef & RIO_PEF_INB_MBOX) && \ + (pef & RIO_PEF_INB_DOORBELL) && \ + (src_ops & RIO_SRC_OPS_DOORBELL) && \ + (dst_ops & RIO_DST_OPS_DOORBELL)) +#define dev_rionet_capable(dev) \ + is_rionet_capable(dev->pef, dev->src_ops, dev->dst_ops) + +#define RIONET_MAC_MATCH(x) (*(u32 *)x == 0x00010001) +#define RIONET_GET_DESTID(x) (*(u16 *)(x + 4)) + +static struct net_device_stats *rionet_stats(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + return &rnet->stats; +} + +static int rionet_rx_clean(struct net_device *ndev) +{ + int i; + int error = 0; + struct rionet_private *rnet = ndev->priv; + void *data; + + i = rnet->rx_slot; + + do { + if (!rnet->rx_skb[i]) { + rnet->stats.rx_dropped++; + continue; + } + + if (!(data = rio_get_inb_message(rnet->mport, RIONET_MAILBOX))) + break; + + rnet->rx_skb[i]->data = data; + skb_put(rnet->rx_skb[i], RIO_MAX_MSG_SIZE); + rnet->rx_skb[i]->dev = sndev; + rnet->rx_skb[i]->protocol = + eth_type_trans(rnet->rx_skb[i], sndev); + error = netif_rx(rnet->rx_skb[i]); + + if (error == NET_RX_DROP) { + rnet->stats.rx_dropped++; + } else if (error == NET_RX_BAD) { + if (netif_msg_rx_err(rnet)) + printk(KERN_WARNING "%s: bad rx packet\n", + DRV_NAME); + rnet->stats.rx_errors++; + } else { + rnet->stats.rx_packets++; + rnet->stats.rx_bytes += RIO_MAX_MSG_SIZE; + } + + } while ((i = (i + 1) % RIONET_RX_RING_SIZE) != rnet->rx_slot); + + return i; +} + +static void rionet_rx_fill(struct net_device *ndev, int end) +{ + int i; + struct rionet_private *rnet = ndev->priv; + + i = rnet->rx_slot; + do { + rnet->rx_skb[i] = dev_alloc_skb(RIO_MAX_MSG_SIZE); + + if (!rnet->rx_skb[i]) + break; + + rio_add_inb_buffer(rnet->mport, RIONET_MAILBOX, + rnet->rx_skb[i]->data); + } while ((i = (i + 1) % RIONET_RX_RING_SIZE) != end); + + rnet->rx_slot = i; +} + +static int rionet_queue_tx_msg(struct sk_buff *skb, struct net_device *ndev, + struct rio_dev *rdev) +{ + struct rionet_private *rnet = ndev->priv; + + rio_add_outb_message(rnet->mport, rdev, 0, skb->data, skb->len); + rnet->tx_skb[rnet->tx_slot] = skb; + + rnet->stats.tx_packets++; + rnet->stats.tx_bytes += skb->len; + + if (++rnet->tx_cnt == RIONET_TX_RING_SIZE) + netif_stop_queue(ndev); + + if (++rnet->tx_slot == RIONET_TX_RING_SIZE) + rnet->tx_slot = 0; + + if (netif_msg_tx_queued(rnet)) + printk(KERN_INFO "%s: queued skb %8.8x len %8.8x\n", DRV_NAME, + (u32) skb, skb->len); + + return 0; +} + +static int rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev) +{ + int i; + struct rionet_private *rnet = ndev->priv; + struct ethhdr *eth = (struct ethhdr *)skb->data; + u16 destid; + + spin_lock_irq(&rnet->lock); + + if ((rnet->tx_cnt + 1) > RIONET_TX_RING_SIZE) { + netif_stop_queue(ndev); + spin_unlock_irq(&rnet->lock); + return -EBUSY; + } + + if (eth->h_dest[0] & 0x01) { + /* + * XXX Need to delay queuing if ring max is reached, + * flush additional packets in tx_event() before + * awakening the queue. We can easily exceed ring + * size with a large number of nodes or even a + * small number where the ring is relatively full + * on entrance to hard_start_xmit. + */ + for (i = 0; i < RIO_MAX_ROUTE_ENTRIES; i++) + if (rionet_active[i]) + rionet_queue_tx_msg(skb, ndev, + rionet_active[i]); + } else if (RIONET_MAC_MATCH(eth->h_dest)) { + destid = RIONET_GET_DESTID(eth->h_dest); + if (rionet_active[destid]) + rionet_queue_tx_msg(skb, ndev, rionet_active[destid]); + } + + spin_unlock_irq(&rnet->lock); + + return 0; +} + +static int rionet_set_mac_address(struct net_device *ndev, void *p) +{ + struct sockaddr *addr = p; + + if (!is_valid_ether_addr(addr->sa_data)) + return -EADDRNOTAVAIL; + + memcpy(ndev->dev_addr, addr->sa_data, ndev->addr_len); + + return 0; +} + +static int rionet_change_mtu(struct net_device *ndev, int new_mtu) +{ + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_drv(rnet)) + printk(KERN_WARNING + "%s: rionet_change_mtu(): not implemented\n", DRV_NAME); + + return 0; +} + +static void rionet_set_multicast_list(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_drv(rnet)) + printk(KERN_WARNING + "%s: rionet_set_multicast_list(): not implemented\n", + DRV_NAME); +} + +static void rionet_dbell_event(struct rio_mport *mport, u16 sid, u16 tid, + u16 info) +{ + struct net_device *ndev = sndev; + struct rionet_private *rnet = ndev->priv; + struct rionet_peer *peer; + + if (netif_msg_intr(rnet)) + printk(KERN_INFO "%s: doorbell sid %4.4x tid %4.4x info %4.4x", + DRV_NAME, sid, tid, info); + if (info == RIONET_DOORBELL_JOIN) { + if (!rionet_active[sid]) { + list_for_each_entry(peer, &rionet_peers, node) { + if (peer->rdev->destid == sid) + rionet_active[sid] = peer->rdev; + } + rio_mport_send_doorbell(mport, sid, + RIONET_DOORBELL_JOIN); + } + } else if (info == RIONET_DOORBELL_LEAVE) { + rionet_active[sid] = NULL; + } else { + if (netif_msg_intr(rnet)) + printk(KERN_WARNING "%s: unhandled doorbell\n", + DRV_NAME); + } +} + +static void rionet_inb_msg_event(struct rio_mport *mport, int mbox, int slot) +{ + int n; + struct net_device *ndev = sndev; + struct rionet_private *rnet = (struct rionet_private *)ndev->priv; + + if (netif_msg_intr(rnet)) + printk(KERN_INFO "%s: inbound message event, mbox %d slot %d\n", + DRV_NAME, mbox, slot); + + spin_lock(&rnet->lock); + if ((n = rionet_rx_clean(ndev)) != rnet->rx_slot) + rionet_rx_fill(ndev, n); + spin_unlock(&rnet->lock); +} + +static void rionet_outb_msg_event(struct rio_mport *mport, int mbox, int slot) +{ + struct net_device *ndev = sndev; + struct rionet_private *rnet = ndev->priv; + + spin_lock(&rnet->lock); + + if (netif_msg_intr(rnet)) + printk(KERN_INFO + "%s: outbound message event, mbox %d slot %d\n", + DRV_NAME, mbox, slot); + + while (rnet->tx_cnt && (rnet->ack_slot != slot)) { + /* dma unmap single */ + dev_kfree_skb_irq(rnet->tx_skb[rnet->ack_slot]); + rnet->tx_skb[rnet->ack_slot] = NULL; + if (++rnet->ack_slot == RIONET_TX_RING_SIZE) + rnet->ack_slot = 0; + rnet->tx_cnt--; + } + + if (rnet->tx_cnt < RIONET_TX_RING_SIZE) + netif_wake_queue(ndev); + + spin_unlock(&rnet->lock); +} + +static int rionet_open(struct net_device *ndev) +{ + int i, rc = 0; + struct rionet_peer *peer, *tmp; + u32 pwdcsr; + struct rionet_private *rnet = ndev->priv; + + if (netif_msg_ifup(rnet)) + printk(KERN_INFO "%s: open\n", DRV_NAME); + + if ((rc = rio_request_inb_dbell(rnet->mport, + RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE, + rionet_dbell_event)) < 0) + goto out; + + if ((rc = rio_request_inb_mbox(rnet->mport, + RIONET_MAILBOX, + RIONET_RX_RING_SIZE, + rionet_inb_msg_event)) < 0) + goto out; + + if ((rc = rio_request_outb_mbox(rnet->mport, + RIONET_MAILBOX, + RIONET_TX_RING_SIZE, + rionet_outb_msg_event)) < 0) + goto out; + + /* Initialize inbound message ring */ + for (i = 0; i < RIONET_RX_RING_SIZE; i++) + rnet->rx_skb[i] = NULL; + rnet->rx_slot = 0; + rionet_rx_fill(ndev, 0); + + rnet->tx_slot = 0; + rnet->tx_cnt = 0; + rnet->ack_slot = 0; + + spin_lock_init(&rnet->lock); + + rnet->msg_enable = RIONET_DEFAULT_MSGLEVEL; + + netif_carrier_on(ndev); + netif_start_queue(ndev); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + if (!(peer->res = rio_request_outb_dbell(peer->rdev, + RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE))) + { + printk(KERN_ERR "%s: error requesting doorbells\n", + DRV_NAME); + continue; + } + + /* + * If device has initialized inbound doorbells, + * send a join message + */ + rio_read_config_32(peer->rdev, RIO_WRITE_PORT_CSR, &pwdcsr); + if (pwdcsr & RIO_DOORBELL_AVAIL) + rio_send_doorbell(peer->rdev, RIONET_DOORBELL_JOIN); + } + + out: + return rc; +} + +static int rionet_close(struct net_device *ndev) +{ + struct rionet_private *rnet = (struct rionet_private *)ndev->priv; + struct rionet_peer *peer, *tmp; + int i; + + if (netif_msg_ifup(rnet)) + printk(KERN_INFO "%s: close\n", DRV_NAME); + + netif_stop_queue(ndev); + netif_carrier_off(ndev); + + for (i = 0; i < RIONET_RX_RING_SIZE; i++) + if (rnet->rx_skb[i]) + kfree_skb(rnet->rx_skb[i]); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + if (rionet_active[peer->rdev->destid]) { + rio_send_doorbell(peer->rdev, RIONET_DOORBELL_LEAVE); + rionet_active[peer->rdev->destid] = NULL; + } + rio_release_outb_dbell(peer->rdev, peer->res); + } + + rio_release_inb_dbell(rnet->mport, RIONET_DOORBELL_JOIN, + RIONET_DOORBELL_LEAVE); + rio_release_inb_mbox(rnet->mport, RIONET_MAILBOX); + rio_release_outb_mbox(rnet->mport, RIONET_MAILBOX); + + return 0; +} + +static void rionet_remove(struct rio_dev *rdev) +{ + struct net_device *ndev = NULL; + struct rionet_peer *peer, *tmp; + + unregister_netdev(ndev); + kfree(ndev); + + list_for_each_entry_safe(peer, tmp, &rionet_peers, node) { + list_del(&peer->node); + kfree(peer); + } +} + +static int rionet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) +{ + return -EOPNOTSUPP; +} + +static void rionet_get_drvinfo(struct net_device *ndev, + struct ethtool_drvinfo *info) +{ + struct rionet_private *rnet = ndev->priv; + + strcpy(info->driver, DRV_NAME); + strcpy(info->version, DRV_VERSION); + strcpy(info->fw_version, "n/a"); + sprintf(info->bus_info, "RIO master port %d", rnet->mport->id); +} + +static u32 rionet_get_msglevel(struct net_device *ndev) +{ + struct rionet_private *rnet = ndev->priv; + + return rnet->msg_enable; +} + +static void rionet_set_msglevel(struct net_device *ndev, u32 value) +{ + struct rionet_private *rnet = ndev->priv; + + rnet->msg_enable = value; +} + +static u32 rionet_get_link(struct net_device *ndev) +{ + return netif_carrier_ok(ndev); +} + +static struct ethtool_ops rionet_ethtool_ops = { + .get_drvinfo = rionet_get_drvinfo, + .get_msglevel = rionet_get_msglevel, + .set_msglevel = rionet_set_msglevel, + .get_link = rionet_get_link, +}; + +static int rionet_setup_netdev(struct rio_mport *mport) +{ + int rc = 0; + struct net_device *ndev = NULL; + struct rionet_private *rnet; + u16 device_id; + + /* Allocate our net_device structure */ + ndev = alloc_etherdev(sizeof(struct rionet_private)); + if (ndev == NULL) { + printk(KERN_INFO "%s: could not allocate ethernet device.\n", + DRV_NAME); + rc = -ENOMEM; + goto out; + } + + /* + * XXX hack, store point a static at ndev so we can get it... + * Perhaps need an array of these that the handler can + * index via the mbox number. + */ + sndev = ndev; + + /* Set up private area */ + rnet = (struct rionet_private *)ndev->priv; + rnet->mport = mport; + + /* Set the default MAC address */ + device_id = rio_local_get_device_id(mport); + ndev->dev_addr[0] = 0x00; + ndev->dev_addr[1] = 0x01; + ndev->dev_addr[2] = 0x00; + ndev->dev_addr[3] = 0x01; + ndev->dev_addr[4] = device_id >> 8; + ndev->dev_addr[5] = device_id & 0xff; + + /* Fill in the driver function table */ + ndev->open = &rionet_open; + ndev->hard_start_xmit = &rionet_start_xmit; + ndev->stop = &rionet_close; + ndev->get_stats = &rionet_stats; + ndev->change_mtu = &rionet_change_mtu; + ndev->set_mac_address = &rionet_set_mac_address; + ndev->set_multicast_list = &rionet_set_multicast_list; + ndev->do_ioctl = &rionet_ioctl; + SET_ETHTOOL_OPS(ndev, &rionet_ethtool_ops); + + ndev->mtu = RIO_MAX_MSG_SIZE - 14; + + SET_MODULE_OWNER(ndev); + + rc = register_netdev(ndev); + if (rc != 0) + goto out; + + printk("%s: %s %s Version %s, MAC %02x:%02x:%02x:%02x:%02x:%02x\n", + ndev->name, + DRV_NAME, + DRV_DESC, + DRV_VERSION, + ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2], + ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]); + + out: + return rc; +} + +/* + * XXX Make multi-net safe + */ +static int rionet_probe(struct rio_dev *rdev, const struct rio_device_id *id) +{ + int rc = -ENODEV; + u32 lpef, lsrc_ops, ldst_ops; + struct rionet_peer *peer; + + /* If local device is not rionet capable, give up quickly */ + if (!rionet_capable) + goto out; + + /* + * First time through, make sure local device is rionet + * capable, setup netdev, and set flags so this is skipped + * on later probes + */ + if (!rionet_check) { + rio_local_read_config_32(rdev->net->hport, RIO_PEF_CAR, &lpef); + rio_local_read_config_32(rdev->net->hport, RIO_SRC_OPS_CAR, + &lsrc_ops); + rio_local_read_config_32(rdev->net->hport, RIO_DST_OPS_CAR, + &ldst_ops); + if (!is_rionet_capable(lpef, lsrc_ops, ldst_ops)) { + printk(KERN_ERR + "%s: local device is not network capable\n", + DRV_NAME); + rionet_check = 1; + rionet_capable = 0; + goto out; + } + + rc = rionet_setup_netdev(rdev->net->hport); + rionet_check = 1; + } + + /* + * If the remote device has mailbox/doorbell capabilities, + * add it to the peer list. + */ + if (dev_rionet_capable(rdev)) { + if (!(peer = kmalloc(sizeof(struct rionet_peer), GFP_KERNEL))) { + rc = -ENOMEM; + goto out; + } + peer->rdev = rdev; + list_add_tail(&peer->node, &rionet_peers); + } + + out: + return rc; +} + +static struct rio_device_id rionet_id_table[] = { + {RIO_DEVICE(RIO_ANY_ID, RIO_ANY_ID)} +}; + +static struct rio_driver rionet_driver = { + .name = "rionet", + .id_table = rionet_id_table, + .probe = rionet_probe, + .remove = rionet_remove, +}; + +static int __init rionet_init(void) +{ + return rio_register_driver(&rionet_driver); +} + +static void __exit rionet_exit(void) +{ + rio_unregister_driver(&rionet_driver); +} + +module_init(rionet_init); +module_exit(rionet_exit); From davem@davemloft.net Thu Jun 2 14:41:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 14:41:19 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52LfFXq028972 for ; Thu, 2 Jun 2005 14:41:15 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdxQ3-00058E-Ju; Thu, 02 Jun 2005 14:40:03 -0700 Date: Thu, 02 Jun 2005 14:40:03 -0700 (PDT) Message-Id: <20050602.144003.35660495.davem@davemloft.net> To: shemminger@osdl.org Cc: john.ronciak@intel.com, hadi@cyberus.ca, jdmason@us.ibm.com, mitch.a.williams@intel.com, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch From: "David S. Miller" In-Reply-To: <20050602143126.7c302cfd@dxpl.pdx.osdl.net> References: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> <20050602143126.7c302cfd@dxpl.pdx.osdl.net> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1077 Lines: 25 From: Stephen Hemminger Date: Thu, 2 Jun 2005 14:31:26 -0700 > For networking the problem is worse, the "right" choice depends on workload > and relationship between components in the system. I can't see how you could > ever expect a driver specific solution. I totally agree, even the mere concept of driver-centric decisions in this area is pretty bogus. > And for other workloads, and other systems (think about the Altix with > long access latencies), your numbers will be wrong. Perhaps we need > to quit trying for a perfect solution and just get a "good enough" one > that works. I don't understand why nobody is investigating doing this stuff by generic measurements that the core kernel can perform. The generic ->poll() runner code can say, wow it took N-usec to process M packets, perhaps I should adjust the weight. I haven't seen one concrete suggestion along those lines, yet that is where the answer to this kind of stuff is. Those kinds of solutions are completely CPU, memory, I/O bus, network device, and workload independant. From jdmason@us.ibm.com Thu Jun 2 14:53:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 14:53:06 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52Lr3Xq000575 for ; Thu, 2 Jun 2005 14:53:03 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j52Lq6mD244468 for ; Thu, 2 Jun 2005 17:52:06 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j52Lq5Jj038004 for ; Thu, 2 Jun 2005 15:52:05 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j52Lq4EK018604 for ; Thu, 2 Jun 2005 15:52:05 -0600 Received: from [192.168.0.29] (dreadnought.austin.ibm.com [9.53.90.32]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j52Lq4KL018571; Thu, 2 Jun 2005 15:52:04 -0600 From: Jon Mason Organization: IBM To: Stephen Hemminger Subject: Re: RFC: NAPI packet weighting patch Date: Thu, 2 Jun 2005 16:51:48 -0500 User-Agent: KMail/1.7.2 Cc: "Ronciak, John" , hadi@cyberus.ca, "David S. Miller" , "Williams, Mitch A" , netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Venkatesan, Ganesh" , "Brandeburg, Jesse" References: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> <20050602143126.7c302cfd@dxpl.pdx.osdl.net> In-Reply-To: <20050602143126.7c302cfd@dxpl.pdx.osdl.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506021651.49013.jdmason@us.ibm.com> X-archive-position: 1992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1355 Lines: 26 On Thursday 02 June 2005 04:31 pm, Stephen Hemminger wrote: <...> > For networking the problem is worse, the "right" choice depends on workload > and relationship between components in the system. I can't see how you > could ever expect a driver specific solution. I think there is a way for a generic driver NAPI enhancement. That is to modify the weight dependent on link speed. Here is the problem as I see it, NAPI enablement for slow media speeds causes unneeded strain on the system. This is because of the "weight" of NAPI. Lets look at e1000 as an example. Currently the NAPI weight is 64, regardless of link media speed. This weight is probably fine for a gigabit link, but for 10/100 this is way to large. Thus causing interrupts to be enabled/disabled after every poll/interrupt. Lots of overhead, and not very smart. Why not have the driver set the weight to 16/32 respectively for the weight (or better yet, have someone run numbers to find weight that are closer to what the adapter can actually use)? While these numbers may not be optimal for every system, this is much better that the current system, and would only require 5 or so extra lines of code per NAPI enabled driver. For those who want to have an optimal weight for their tuned system, let them use the /proc entry that is being proposed. Thanks, Jon From shemminger@osdl.org Thu Jun 2 15:06:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 15:06:48 -0700 (PDT) Received: from smtp.osdl.org (fire.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52M6jXq001487 for ; Thu, 2 Jun 2005 15:06:45 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j52M5hjA021673 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Jun 2005 15:05:43 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j52M5hJ8021042; Thu, 2 Jun 2005 15:05:43 -0700 Date: Thu, 2 Jun 2005 15:05:43 -0700 From: Stephen Hemminger To: Matt Porter Cc: torvalds@osdl.org, akpm@osdl.org, jgarzik@pobox.com, linux-kernel@vger.kernel.org, linuxppc-embedded@ozlabs.org, netdev@oss.sgi.com Subject: Re: [PATCH][5/5] RapidIO support: net driver over messaging Message-ID: <20050602150543.7e4326b6@dxpl.pdx.osdl.net> In-Reply-To: <20050602143404.F24818@cox.net> References: <20050602140359.B24818@cox.net> <20050602141247.C24818@cox.net> <20050602141946.D24818@cox.net> <20050602142509.E24818@cox.net> <20050602143404.F24818@cox.net> Organization: Open Source Development Lab X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.109 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 1993 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3600 Lines: 131 How much is this like ethernet? does it still do ARP? Can it do promiscious receive? > +LIST_HEAD(rionet_peers); Does this have to be global? Not sure about the locking of this stuff, are you relying on the RTNL? > + > +static int rionet_change_mtu(struct net_device *ndev, int new_mtu) > +{ > + struct rionet_private *rnet = ndev->priv; > + > + if (netif_msg_drv(rnet)) > + printk(KERN_WARNING > + "%s: rionet_change_mtu(): not implemented\n", DRV_NAME); > + > + return 0; > +} If you can allow any mtu then don't need this at all. Or if you are limited then better return an error for bad values. > +static void rionet_set_multicast_list(struct net_device *ndev) > +{ > + struct rionet_private *rnet = ndev->priv; > + > + if (netif_msg_drv(rnet)) > + printk(KERN_WARNING > + "%s: rionet_set_multicast_list(): not implemented\n", > + DRV_NAME); > +} If you can't handle it then just leave dev->set_multicast_list as NULL and all attempts to add or delete will get -EINVAL > + > +static int rionet_open(struct net_device *ndev) > +{ > + /* Initialize inbound message ring */ > + for (i = 0; i < RIONET_RX_RING_SIZE; i++) > + rnet->rx_skb[i] = NULL; > + rnet->rx_slot = 0; > + rionet_rx_fill(ndev, 0); > + > + rnet->tx_slot = 0; > + rnet->tx_cnt = 0; > + rnet->ack_slot = 0; > + > + spin_lock_init(&rnet->lock); > + > + rnet->msg_enable = RIONET_DEFAULT_MSGLEVEL; Better to do all initialization of the per device data in the place it is allocated (rio_setup_netdev) > + > +static int rionet_ioctl(struct net_device *ndev, struct ifreq *rq, int cmd) > +{ > + return -EOPNOTSUPP; > +} Unneeded, if dev->do_ioctl is NULL, then all private ioctl's will return -EINVAL that is what you want. > + > +static u32 rionet_get_link(struct net_device *ndev) > +{ > + return netif_carrier_ok(ndev); > +} Use ethtool_op_get_link > + > +static int rionet_setup_netdev(struct rio_mport *mport) > +{ > + int rc = 0; > + struct net_device *ndev = NULL; > + struct rionet_private *rnet; > + u16 device_id; > + > + /* Allocate our net_device structure */ > + ndev = alloc_etherdev(sizeof(struct rionet_private)); > + if (ndev == NULL) { > + printk(KERN_INFO "%s: could not allocate ethernet device.\n", > + DRV_NAME); > + rc = -ENOMEM; > + goto out; > + } > + > + /* > + * XXX hack, store point a static at ndev so we can get it... > + * Perhaps need an array of these that the handler can > + * index via the mbox number. > + */ > + sndev = ndev; > + > + /* Set up private area */ > + rnet = (struct rionet_private *)ndev->priv; > + rnet->mport = mport; > + > + /* Set the default MAC address */ > + device_id = rio_local_get_device_id(mport); > + ndev->dev_addr[0] = 0x00; > + ndev->dev_addr[1] = 0x01; > + ndev->dev_addr[2] = 0x00; > + ndev->dev_addr[3] = 0x01; > + ndev->dev_addr[4] = device_id >> 8; > + ndev->dev_addr[5] = device_id & 0xff; > + > + /* Fill in the driver function table */ > + ndev->open = &rionet_open; > + ndev->hard_start_xmit = &rionet_start_xmit; > + ndev->stop = &rionet_close; > + ndev->get_stats = &rionet_stats; > + ndev->change_mtu = &rionet_change_mtu; > + ndev->set_mac_address = &rionet_set_mac_address; > + ndev->set_multicast_list = &rionet_set_multicast_list; > + ndev->do_ioctl = &rionet_ioctl; > + SET_ETHTOOL_OPS(ndev, &rionet_ethtool_ops); > + > + ndev->mtu = RIO_MAX_MSG_SIZE - 14; > + > + SET_MODULE_OWNER(ndev); Can you set any ndev->features to get better performance. Can you take >32bit data addresses? then set HIGHDMA You are doing your on locking, can you use LLTX? Does the hardware support scatter gather? From davem@davemloft.net Thu Jun 2 15:13:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 15:13:27 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52MDOXq002149 for ; Thu, 2 Jun 2005 15:13:24 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdxvA-0005GI-CT; Thu, 02 Jun 2005 15:12:12 -0700 Date: Thu, 02 Jun 2005 15:12:12 -0700 (PDT) Message-Id: <20050602.151212.35014607.davem@davemloft.net> To: jdmason@us.ibm.com Cc: shemminger@osdl.org, john.ronciak@intel.com, hadi@cyberus.ca, mitch.a.williams@intel.com, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch From: "David S. Miller" In-Reply-To: <200506021651.49013.jdmason@us.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> <20050602143126.7c302cfd@dxpl.pdx.osdl.net> <200506021651.49013.jdmason@us.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1994 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 880 Lines: 20 From: Jon Mason Date: Thu, 2 Jun 2005 16:51:48 -0500 > Why not have the driver set the weight to 16/32 respectively for the > weight (or better yet, have someone run numbers to find weight that > are closer to what the adapter can actually use)? While these > numbers may not be optimal for every system, this is much better > that the current system, and would only require 5 or so extra lines > of code per NAPI enabled driver. Why do this when we can adjust the weight in one spot, namely the upper level NAPI ->poll() running loop? It can measure the overhead, how many packets processed, etc. and make intelligent decisions based upon that. This is a CPU speed, memory speed, I/O bus speed, and link speed agnostic solution. The driver need not take any part in this, and the scheme will dynamically adjust to resource usage changes in the system. From Robert.Olsson@data.slu.se Thu Jun 2 15:17:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 15:17:14 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52MH4Xq002804 for ; Thu, 2 Jun 2005 15:17:05 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j52MFs9E022315; Fri, 3 Jun 2005 00:15:54 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 45CA6EE3F0; Fri, 3 Jun 2005 00:15:51 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17055.34070.718986.664873@robur.slu.se> Date: Fri, 3 Jun 2005 00:15:50 +0200 To: Jon Mason Cc: Stephen Hemminger , "Ronciak, John" , hadi@cyberus.ca, "David S. Miller" , "Williams, Mitch A" , netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch In-Reply-To: <200506021651.49013.jdmason@us.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> <20050602143126.7c302cfd@dxpl.pdx.osdl.net> <200506021651.49013.jdmason@us.ibm.com> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 1995 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1819 Lines: 43 Differentiate the meaning of weight a bit. Let weight only limit the number of pkts we deliver per ->poll Have some other mechanism or threshold to control when interrupts are to be turned on. The first approximation for this could be to poll as long as we see any pkt on the RX ring. As interrupt seems expensive on all platforms. Cheers. --ro Jon Mason writes: > On Thursday 02 June 2005 04:31 pm, Stephen Hemminger wrote: > <...> > > For networking the problem is worse, the "right" choice depends on workload > > and relationship between components in the system. I can't see how you > > could ever expect a driver specific solution. > > I think there is a way for a generic driver NAPI enhancement. That is to > modify the weight dependent on link speed. > > Here is the problem as I see it, NAPI enablement for slow media speeds causes > unneeded strain on the system. This is because of the "weight" of NAPI. > Lets look at e1000 as an example. Currently the NAPI weight is 64, > regardless of link media speed. This weight is probably fine for a gigabit > link, but for 10/100 this is way to large. Thus causing interrupts to be > enabled/disabled after every poll/interrupt. Lots of overhead, and not very > smart. Why not have the driver set the weight to 16/32 respectively for the > weight (or better yet, have someone run numbers to find weight that are > closer to what the adapter can actually use)? While these numbers may not be > optimal for every system, this is much better that the current system, and > would only require 5 or so extra lines of code per NAPI enabled driver. > > For those who want to have an optimal weight for their tuned system, let them > use the /proc entry that is being proposed. > > Thanks, > Jon From jdmason@us.ibm.com Thu Jun 2 15:21:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 15:21:04 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52ML0Xq003409 for ; Thu, 2 Jun 2005 15:21:00 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j52MK3mD022896 for ; Thu, 2 Jun 2005 18:20:03 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j52MK2uC222176 for ; Thu, 2 Jun 2005 16:20:02 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j52MK1bg015726 for ; Thu, 2 Jun 2005 16:20:02 -0600 Received: from [192.168.0.29] (dreadnought.austin.ibm.com [9.53.90.32]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j52MK1hV015713; Thu, 2 Jun 2005 16:20:01 -0600 From: Jon Mason Organization: IBM To: "David S. Miller" Subject: Re: RFC: NAPI packet weighting patch Date: Thu, 2 Jun 2005 17:19:46 -0500 User-Agent: KMail/1.7.2 Cc: shemminger@osdl.org, john.ronciak@intel.com, hadi@cyberus.ca, mitch.a.williams@intel.com, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com References: <468F3FDA28AA87429AD807992E22D07E0450BFD0@orsmsx408> <200506021651.49013.jdmason@us.ibm.com> <20050602.151212.35014607.davem@davemloft.net> In-Reply-To: <20050602.151212.35014607.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506021719.47459.jdmason@us.ibm.com> X-archive-position: 1996 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jdmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1047 Lines: 23 On Thursday 02 June 2005 05:12 pm, David S. Miller wrote: > From: Jon Mason > Date: Thu, 2 Jun 2005 16:51:48 -0500 > > > Why not have the driver set the weight to 16/32 respectively for the > > weight (or better yet, have someone run numbers to find weight that > > are closer to what the adapter can actually use)? While these > > numbers may not be optimal for every system, this is much better > > that the current system, and would only require 5 or so extra lines > > of code per NAPI enabled driver. > > Why do this when we can adjust the weight in one spot, > namely the upper level NAPI ->poll() running loop? > > It can measure the overhead, how many packets processed, etc. > and make intelligent decisions based upon that. This is a CPU > speed, memory speed, I/O bus speed, and link speed agnostic > solution. > > The driver need not take any part in this, and the scheme will > dynamically adjust to resource usage changes in the system. Yes, a much better idea to do this generically. I 100% agree with you. From hadi@cyberus.ca Thu Jun 2 15:22:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 15:22:54 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52MMkXq003771 for ; Thu, 2 Jun 2005 15:22:46 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1Ddy4U-0008Hr-T6 for netdev@oss.sgi.com; Thu, 02 Jun 2005 18:21:50 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DdpmN-0002Jn-DX; Thu, 02 Jun 2005 09:30:35 -0400 Subject: Re: PATCH: explicit typing WAS(Re: PATCH: rtnetlink explicit flags setting From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: tgraf@suug.ch, netdev@oss.sgi.com In-Reply-To: <1117717493.6050.29.camel@localhost.localdomain> References: <1117197157.6688.24.camel@localhost.localdomain> <20050531.144338.112623594.davem@davemloft.net> <20050531222646.GK15391@postel.suug.ch> <20050531.153125.95894437.davem@davemloft.net> <1117717493.6050.29.camel@localhost.localdomain> Content-Type: text/plain Organization: unknown Date: Thu, 02 Jun 2005 09:30:32 -0400 Message-Id: <1117719032.6050.50.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 1997 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 344 Lines: 17 I should say this patch is against net-2.6.13.git as of 6am this morning. cheers, jamal On Thu, 2005-02-06 at 09:04 -0400, jamal wrote: > ------------- > This patch converts "unsigned flags" to use more explict types like u16 > instead and incrementally introduces NLMSG_NEW(). > > Signed-off-by: Jamal Hadi Salim > From ravinandan.arakali@neterion.com Thu Jun 2 16:20:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 16:20:39 -0700 (PDT) Received: from ns1.s2io.com (ns1.s2io.com [142.46.200.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52NKZXq010483 for ; Thu, 2 Jun 2005 16:20:36 -0700 Received: from guinness.s2io.com (sentry.s2io.com [142.46.200.199]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id j52NJ5OC005380; Thu, 2 Jun 2005 19:19:05 -0400 (EDT) Received: from rarakali ([10.16.16.57]) by guinness.s2io.com (8.12.6/8.12.6) with SMTP id j52NJ1VG016944; Thu, 2 Jun 2005 19:19:02 -0400 (EDT) From: "Ravinandan Arakali" To: "'David S. Miller'" Cc: , , , , , Subject: RE: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature Date: Thu, 2 Jun 2005 16:18:55 -0700 Message-ID: <003201c567c9$73322240$3910100a@pc.s2io.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20050527.120215.26278001.davem@davemloft.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-archive-position: 1998 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Content-Length: 1822 Lines: 52 David, Since there seems to be pros and cons for both the approaches, we are planning to submit two separate patches(one for each approach). These patches also include the ethtool changes. In terms of performance, we did not observe any diff between the two approaches although the first approach(using SG) minimizes coalescing in driver. Also, some changes will be required in the ethtool user-level utility. I'm not sure if this is the right forum to submit patches for the ethtool utility as well.. Thanks, Ravi -----Original Message----- From: David S. Miller [mailto:davem@davemloft.net] Sent: Friday, May 27, 2005 12:02 PM To: ravinandan.arakali@neterion.com Cc: jgarzik@pobox.com; netdev@oss.sgi.com; raghavendra.koushik@neterion.com; leonid.grossman@neterion.com; ananda.raju@neterion.com; rapuru.sriram@neterion.com Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature From: "Ravinandan Arakali" Date: Fri, 27 May 2005 09:32:00 -0700 > Thanks for the quick feedback. > At that time when we considered using skb_shinfo(skb)->fraglist, > it contained fragments of MTU size. So, for a 60k udp datagram > and 1500 MTU we will have 60k/1500 = 45 fragments which is > more than MAX_SKB_FRAGS(18). > > However we will relook at fraglist for the possibility of increasing > frag size to >MTU. MAX_SKB_FRAGS controls the limit of skb_shinfo(skb)->frags[] entries, not how many SKBs may be chained via skb_shinfo(skb)->fraglist, there is no limit on the latter. Note that there is much coalescing that can be performed on the SKB list data areas, particularly if UDP sendfile() is being used. But such coalescing is messy to be performing inside of the drivers. It may end up being the case that your approach ends up being a better one for these reasons. From davem@davemloft.net Thu Jun 2 16:23:13 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 16:23:15 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52NNCXq010825 for ; Thu, 2 Jun 2005 16:23:13 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Ddz0m-0006ic-Pq; Thu, 02 Jun 2005 16:22:04 -0700 Date: Thu, 02 Jun 2005 16:22:04 -0700 (PDT) Message-Id: <20050602.162204.68041633.davem@davemloft.net> To: ravinandan.arakali@neterion.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, raghavendra.koushik@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature From: "David S. Miller" In-Reply-To: <003201c567c9$73322240$3910100a@pc.s2io.com> References: <20050527.120215.26278001.davem@davemloft.net> <003201c567c9$73322240$3910100a@pc.s2io.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1999 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 831 Lines: 20 From: "Ravinandan Arakali" Date: Thu, 2 Jun 2005 16:18:55 -0700 > Since there seems to be pros and cons for both the approaches, we are > planning > to submit two separate patches(one for each approach). These patches also > include the ethtool changes. In terms of performance, we did not observe any > diff between the two approaches although the first approach(using SG) > minimizes > coalescing in driver. Ok. I think minimizing driver specific work is probably going to make the SG approach more desirable, but we'll see. > Also, some changes will be required in the ethtool user-level utility. > I'm not sure if this is the right forum to submit patches for the ethtool > utility as well.. Making sure jgarzik@pobox.com gets the patch is usually the way to go wrt. ethtool submissions. From davem@davemloft.net Thu Jun 2 16:37:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 16:37:41 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52NbaXq012155 for ; Thu, 2 Jun 2005 16:37:36 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdzEi-0007AN-Q4; Thu, 02 Jun 2005 16:36:28 -0700 Date: Thu, 02 Jun 2005 16:36:28 -0700 (PDT) Message-Id: <20050602.163628.01205145.davem@davemloft.net> To: hch@lst.de Cc: netdev@oss.sgi.com Subject: Re: [PATCH] shaper.c: fix locking From: "David S. Miller" In-Reply-To: <20050601052149.GA11935@lst.de> References: <20050527115450.GA19469@lst.de> <20050531.144114.78710204.davem@davemloft.net> <20050601052149.GA11935@lst.de> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2001 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 927 Lines: 22 From: Christoph Hellwig Date: Wed, 1 Jun 2005 07:21:50 +0200 > On Tue, May 31, 2005 at 02:41:14PM -0700, David S. Miller wrote: > > From: Christoph Hellwig > > Subject: [PATCH] shaper.c: fix locking > > Date: Fri, 27 May 2005 13:54:50 +0200 > > > > > o use a semaphore instead of an opencoded and racy lock > > > o move locking out of shaper_kick and into the callers - most just > > > released the lock before calling shaper_kick > > > o remove in_interrupt() tests. from ->close we can always block, from > > > ->hard_start_xmit and timer context never > > > > Do you really want to use a semaphore for a lock taken > > %99 of the time in software IRQ context, which obviously > > cannot sleep? > > I want to change as little as possible from the previous variant ;-) Fair enough, patch applied. If this driver breaks as a result of these changes, you get to keep the pieces ok? :-) From davem@davemloft.net Thu Jun 2 16:36:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 16:36:25 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52NaJXq011978 for ; Thu, 2 Jun 2005 16:36:19 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdzDU-00073m-CE; Thu, 02 Jun 2005 16:35:12 -0700 Date: Thu, 02 Jun 2005 16:35:12 -0700 (PDT) Message-Id: <20050602.163512.10298458.davem@davemloft.net> To: baruch@ev-en.org Cc: netdev@oss.sgi.com, shemminger@osdl.org, doug.leith@nuim.ie Subject: Re: Comparison of several congestion control algorithms From: "David S. Miller" In-Reply-To: <4298E045.9050009@ev-en.org> References: <4298E045.9050009@ev-en.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2000 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1163 Lines: 24 From: Baruch Even Date: Sat, 28 May 2005 22:19:01 +0100 > I wanted to point you to a comparison of congestion control algorithm > done at the Hamilton Institute. These experiments compare Scalable-TCP, > High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP and Standard TCP. They compared > fairness, compatibility with TCP and link utilisation. > > You can find the results and a report at http://hamilton.ie/net/eval/ Nice work, I enjoyed this paper very much. There is something that none of these papers mention, but is essential for interpreting results. Did you use interfaces with TSO enabled? There is a very serious congestion window growth bug with TSO enabled in the current 2.6.x tree. The problem is due to congestion window validation. When we build TSO frames, even if we have packets to send, we may defer a few frames until the full TSO packet can go out. But this causes the congestion window validation checks in tcp_ack() to not pass, and thus the congestion window does not grow. I am going to have this fixed, but for now people should do congestion window algorithm tests with TSO explicitly disabled on their interfaces. From baruch@ev-en.org Thu Jun 2 16:51:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 16:51:14 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52NpAXq013555 for ; Thu, 2 Jun 2005 16:51:10 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 1AFEF11A953; Fri, 3 Jun 2005 02:50:12 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 3141E11A951; Fri, 3 Jun 2005 02:50:08 +0300 (IDT) Message-ID: <429F9B2F.8030507@ev-en.org> Date: Fri, 03 Jun 2005 00:50:07 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com, shemminger@osdl.org, doug.leith@nuim.ie Subject: Re: Comparison of several congestion control algorithms References: <4298E045.9050009@ev-en.org> <20050602.163512.10298458.davem@davemloft.net> In-Reply-To: <20050602.163512.10298458.davem@davemloft.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 2002 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 1075 Lines: 28 David S. Miller wrote: > From: Baruch Even > Date: Sat, 28 May 2005 22:19:01 +0100 > > >>I wanted to point you to a comparison of congestion control algorithm >>done at the Hamilton Institute. These experiments compare Scalable-TCP, >>High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP and Standard TCP. They compared >> fairness, compatibility with TCP and link utilisation. >> >>You can find the results and a report at http://hamilton.ie/net/eval/ > > > Nice work, I enjoyed this paper very much. > > There is something that none of these papers mention, but is essential > for interpreting results. Did you use interfaces with TSO enabled? I did not do these experiments myself, but to the best of my knowledge, none of the experiments done so far in Hamilton have used the TSO feature. This is in part because of the start of the work that was based on 2.4 kernels and even as far as the 2.6.6 kernel which had disabled TSO once it saw SACKs. This made TSO unusable for our needs. AFAIK, the tests reported in that document used kernel 2.6.6. Baruch From davem@davemloft.net Thu Jun 2 16:54:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 16:54:46 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j52NsfXq014133 for ; Thu, 2 Jun 2005 16:54:41 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DdzVO-0000j6-1S; Thu, 02 Jun 2005 16:53:42 -0700 Date: Thu, 02 Jun 2005 16:53:41 -0700 (PDT) Message-Id: <20050602.165341.63126720.davem@davemloft.net> To: baruch@ev-en.org Cc: netdev@oss.sgi.com, shemminger@osdl.org, doug.leith@nuim.ie Subject: Re: Comparison of several congestion control algorithms From: "David S. Miller" In-Reply-To: <429F9B2F.8030507@ev-en.org> References: <4298E045.9050009@ev-en.org> <20050602.163512.10298458.davem@davemloft.net> <429F9B2F.8030507@ev-en.org> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2003 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 689 Lines: 18 From: Baruch Even Date: Fri, 03 Jun 2005 00:50:07 +0100 > This is in part because of the start of the work that was based on 2.4 > kernels and even as far as the 2.6.6 kernel which had disabled TSO once > it saw SACKs. This made TSO unusable for our needs. > > AFAIK, the tests reported in that document used kernel 2.6.6. Sure SACKs turn off TSO currently, but you'll have them enabled at the beginning until the first loss and this affects how fast the cwnd will grow. If you have e1000 cards, for example, you're getting TSO enabled by default. You really need to look into this, as it has a real and very non-trivial effect on all of the results you obtained. From john.ronciak@intel.com Thu Jun 2 17:14:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 17:14:47 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j530EYXq015670 for ; Thu, 2 Jun 2005 17:14:35 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j530CDM3022374; Fri, 3 Jun 2005 00:12:13 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j530CCh0023812; Fri, 3 Jun 2005 00:12:13 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005060217121301969 ; Thu, 02 Jun 2005 17:12:13 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Jun 2005 17:11:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC: NAPI packet weighting patch Date: Thu, 2 Jun 2005 17:11:20 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0450BFDB@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: NAPI packet weighting patch Thread-Index: AcVnwTswxSKQFuwsSBqFR1SjFJna0QADuSdA From: "Ronciak, John" To: "Jon Mason" , "David S. Miller" Cc: , , "Williams, Mitch A" , , , "Venkatesan, Ganesh" , "Brandeburg, Jesse" X-OriginalArrivalTime: 03 Jun 2005 00:11:21.0645 (UTC) FILETIME=[C5A105D0:01C567D0] X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j530EYXq015670 X-archive-position: 2005 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: john.ronciak@intel.com Precedence: bulk X-list: netdev Content-Length: 1961 Lines: 53 I like this idea as well but I do an issue with it. How would this stack code find out that the weight is too high and pacekts are being dropped (not being polled fast enough)? It would have to check the controller stats to see the error count increasing for some period. I'm not sure this is workable unless we have some sort of feedback which the driver could send up (or set) saying that this is happening and the dynamic weight code could take into acount. Comments? Cheers, John > -----Original Message----- > From: Jon Mason [mailto:jdmason@us.ibm.com] > Sent: Thursday, June 02, 2005 3:20 PM > To: David S. Miller > Cc: shemminger@osdl.org; Ronciak, John; hadi@cyberus.ca; > Williams, Mitch A; netdev@oss.sgi.com; > Robert.Olsson@data.slu.se; Venkatesan, Ganesh; Brandeburg, Jesse > Subject: Re: RFC: NAPI packet weighting patch > > > On Thursday 02 June 2005 05:12 pm, David S. Miller wrote: > > From: Jon Mason > > Date: Thu, 2 Jun 2005 16:51:48 -0500 > > > > > Why not have the driver set the weight to 16/32 > respectively for the > > > weight (or better yet, have someone run numbers to find > weight that > > > are closer to what the adapter can actually use)? While these > > > numbers may not be optimal for every system, this is much better > > > that the current system, and would only require 5 or so > extra lines > > > of code per NAPI enabled driver. > > > > Why do this when we can adjust the weight in one spot, > > namely the upper level NAPI ->poll() running loop? > > > > It can measure the overhead, how many packets processed, etc. > > and make intelligent decisions based upon that. This is a CPU > > speed, memory speed, I/O bus speed, and link speed agnostic > > solution. > > > > The driver need not take any part in this, and the scheme will > > dynamically adjust to resource usage changes in the system. > > Yes, a much better idea to do this generically. I 100% agree > with you. > From hadi@cyberus.ca Thu Jun 2 17:14:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 17:14:39 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j530EYXq015668 for ; Thu, 2 Jun 2005 17:14:35 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1Ddzoj-0001X1-Ur for netdev@oss.sgi.com; Thu, 02 Jun 2005 20:13:41 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Ddq7c-0005rn-D5; Thu, 02 Jun 2005 09:52:32 -0400 Subject: PATCH: ioctl send PID in netlink events From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: netdev Content-Type: multipart/mixed; boundary="=-Vf8rMgMoYxExZv+wVDZr" Organization: unknown Date: Thu, 02 Jun 2005 09:52:29 -0400 Message-Id: <1117720349.6050.59.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 2004 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 4221 Lines: 131 --=-Vf8rMgMoYxExZv+wVDZr Content-Type: text/plain Content-Transfer-Encoding: 7bit This is where i was trying to get to ;-> This patch is on top of the earlier one i sent for explicit types. I still have to think about how to best do IPV6 routes as well as ARP and NDISC. If anyone has suggestions or wants to tackle them let me know, the v6 route is not going to be a pretty one i think. cheers, jamal This patch ensures that netlink events created as a result of programns using ioctls (such as ifconfig, route etc) contains the correct PID of those events. Signed-off-by: Jamal Hadi Salim --=-Vf8rMgMoYxExZv+wVDZr Content-Disposition: attachment; filename=ifconf_pid_p Content-Type: text/plain; name=ifconf_pid_p; charset=UTF-8 Content-Transfer-Encoding: 7bit net/core/rtnetlink.c: needs update net/ipv4/devinet.c: needs update net/ipv4/fib_semantics.c: needs update net/ipv6/addrconf.c: needs update Index: net/core/rtnetlink.c =================================================================== --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/core/rtnetlink.c (mode:100644) +++ uncommitted/net/core/rtnetlink.c (mode:100644) @@ -452,7 +452,7 @@ if (!skb) return; - if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change, 0) < 0) { + if (rtnetlink_fill_ifinfo(skb, dev, type, current->pid, 0, change, 0) < 0) { kfree_skb(skb); return; } Index: net/ipv4/devinet.c =================================================================== --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/devinet.c (mode:100644) +++ uncommitted/net/ipv4/devinet.c (mode:100644) @@ -236,6 +236,7 @@ struct in_ifaddr *promote = NULL; struct in_ifaddr *ifa1 = *ifap; + printk("inet_del_ifa: pid %d\n",current->pid); ASSERT_RTNL(); /* 1. Deleting primary ifaddr forces deletion all secondaries @@ -305,6 +306,7 @@ ASSERT_RTNL(); + printk("inet_insert_ifa: pid %d\n",current->pid); if (!ifa->ifa_local) { inet_free_ifa(ifa); return 0; @@ -1112,7 +1114,7 @@ if (!skb) netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, ENOBUFS); - else if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { + else if (inet_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, EINVAL); } else { Index: net/ipv4/fib_semantics.c =================================================================== --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/fib_semantics.c (mode:100644) +++ uncommitted/net/ipv4/fib_semantics.c (mode:100644) @@ -276,7 +276,7 @@ struct nlmsghdr *n, struct netlink_skb_parms *req) { struct sk_buff *skb; - u32 pid = req ? req->pid : 0; + u32 pid = req ? req->pid : n->nlmsg_pid; int size = NLMSG_SPACE(sizeof(struct rtmsg)+256); skb = alloc_skb(size, GFP_KERNEL); @@ -1035,7 +1035,7 @@ } nl->nlmsg_flags = NLM_F_REQUEST; - nl->nlmsg_pid = 0; + nl->nlmsg_pid = current->pid; nl->nlmsg_seq = 0; nl->nlmsg_len = NLMSG_LENGTH(sizeof(*rtm)); if (cmd == SIOCDELRT) { Index: net/ipv6/addrconf.c =================================================================== --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv6/addrconf.c (mode:100644) +++ uncommitted/net/ipv6/addrconf.c (mode:100644) @@ -2872,7 +2872,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, ENOBUFS); return; } - if (inet6_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { + if (inet6_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, EINVAL); return; @@ -3007,7 +3007,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, ENOBUFS); return; } - if (inet6_fill_ifinfo(skb, idev, 0, 0, event, 0) < 0) { + if (inet6_fill_ifinfo(skb, idev, current->pid, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, EINVAL); return; @@ -3064,7 +3064,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, ENOBUFS); return; } - if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event, 0) < 0) { + if (inet6_fill_prefix(skb, idev, pinfo, current->pid, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, EINVAL); return; --=-Vf8rMgMoYxExZv+wVDZr-- From davem@davemloft.net Thu Jun 2 17:19:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 17:19:24 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j530JKXq016790 for ; Thu, 2 Jun 2005 17:19:21 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1Ddzt6-0001j3-Rq; Thu, 02 Jun 2005 17:18:12 -0700 Date: Thu, 02 Jun 2005 17:18:12 -0700 (PDT) Message-Id: <20050602.171812.48807872.davem@davemloft.net> To: john.ronciak@intel.com Cc: jdmason@us.ibm.com, shemminger@osdl.org, hadi@cyberus.ca, mitch.a.williams@intel.com, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch From: "David S. Miller" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0450BFDB@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0450BFDB@orsmsx408> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2006 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 827 Lines: 15 From: "Ronciak, John" Date: Thu, 2 Jun 2005 17:11:20 -0700 > I like this idea as well but I do an issue with it. How would this > stack code find out that the weight is too high and pacekts are being > dropped (not being polled fast enough)? It would have to check the > controller stats to see the error count increasing for some period. I'm > not sure this is workable unless we have some sort of feedback which the > driver could send up (or set) saying that this is happening and the > dynamic weight code could take into acount. What more do you need other than checking the statistics counter? The drop statistics (the ones we care about) are incremented in real time by the ->poll() code, so it's not like we have to trigger some asynchronous event to get a current version of the number. From ravinandan.arakali@neterion.com Thu Jun 2 17:51:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 17:51:40 -0700 (PDT) Received: from linux.site (adsl-67-120-213-161.dsl.sntc01.pacbell.net [67.120.213.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j530paXq018846 for ; Thu, 2 Jun 2005 17:51:36 -0700 Received: by linux.site (Postfix, from userid 0) id 28C4B7B99F; Thu, 2 Jun 2005 17:43:58 -0700 (PDT) To: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com Cc: raghavendra.koushik@neterion.com, ravinandan.arakali@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com From: ravinandan.arakali@neterion.com Subject: [PATCH 2.6.12-rc4] ethtool: Support for UDP Large Send Offload Message-Id: <20050603004358.28C4B7B99F@linux.site> Date: Thu, 2 Jun 2005 17:43:58 -0700 (PDT) X-archive-position: 2009 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Content-Length: 3847 Lines: 136 Hi, Attached below is a patch on ethtool utility to support USO(UDP Large Send Offload). Pls review the patch. Usage: 1. To view USO setting # ethtool -k 2. To set/unset USO # ethtool -K uso on|off Signed-off-by: Ananda Raju Signed-off-by: Ravinandan Arakali --- diff -uNr ethtool-3/ethtool-copy.h ethtool-3_uso/ethtool-copy.h --- ethtool-3/ethtool-copy.h 2005-01-28 01:50:26.000000000 +0545 +++ ethtool-3_uso/ethtool-copy.h 2005-06-02 23:06:48.000000000 +0545 @@ -283,6 +283,8 @@ #define ETHTOOL_GSTATS 0x0000001d /* get NIC-specific statistics */ #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ +#define ETHTOOL_GUSO 0x00000020 /* Get USO enable (ethtool_value) */ +#define ETHTOOL_SUSO 0x00000021 /* Set USO enable (ethtool_value) */ /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET diff -uNr ethtool-3/ethtool.c ethtool-3_uso/ethtool.c --- ethtool-3/ethtool.c 2005-01-28 04:19:29.000000000 +0545 +++ ethtool-3_uso/ethtool.c 2005-06-02 23:06:52.000000000 +0545 @@ -119,6 +119,7 @@ * [ tx on|off ] \ * [ sg on|off ] \ * [ tso on|off ] + * [ uso on|off ] * ethtool -r DEVNAME * ethtool -p DEVNAME [ %d ] * ethtool -t DEVNAME [ online|offline ] @@ -191,6 +192,7 @@ " [ tx on|off ] \\\n" " [ sg on|off ] \\\n" " [ tso on|off ]\n" + " [ uso on|off ]\n" " ethtool -r DEVNAME\n" " ethtool -p DEVNAME [ %%d ]\n" " ethtool -t DEVNAME [online|(offline)]\n" @@ -236,6 +238,7 @@ static int off_csum_tx_wanted = -1; static int off_sg_wanted = -1; static int off_tso_wanted = -1; +static int off_uso_wanted = -1; static struct ethtool_pauseparam epause; static int gpause_changed = 0; @@ -339,6 +342,7 @@ { "tx", CMDL_BOOL, &off_csum_tx_wanted, NULL }, { "sg", CMDL_BOOL, &off_sg_wanted, NULL }, { "tso", CMDL_BOOL, &off_tso_wanted, NULL }, + { "uso", CMDL_BOOL, &off_uso_wanted, NULL }, }; static struct cmdline_info cmdline_pause[] = { @@ -1184,17 +1188,19 @@ return 0; } -static int dump_offload (int rx, int tx, int sg, int tso) +static int dump_offload (int rx, int tx, int sg, int tso, int uso) { fprintf(stdout, "rx-checksumming: %s\n" "tx-checksumming: %s\n" "scatter-gather: %s\n" - "tcp segmentation offload: %s\n", + "tcp segmentation offload: %s\n" + "udp large send offload: %s\n", rx ? "on" : "off", tx ? "on" : "off", sg ? "on" : "off", - tso ? "on" : "off"); + tso ? "on" : "off", + uso ? "on" : "off"); return 0; } @@ -1458,7 +1464,7 @@ static int do_goffload(int fd, struct ifreq *ifr) { struct ethtool_value eval; - int err, allfail = 1, rx = 0, tx = 0, sg = 0, tso = 0; + int err, allfail = 1, rx = 0, tx = 0, sg = 0, tso = 0, uso = 0; fprintf(stdout, "Offload parameters for %s:\n", devname); @@ -1502,12 +1508,22 @@ allfail = 0; } + eval.cmd = ETHTOOL_GUSO; + ifr->ifr_data = (caddr_t)&eval; + err = ioctl(fd, SIOCETHTOOL, ifr); + if (err) + perror("Cannot get device udp large send offload settings"); + else { + uso = eval.data; + allfail = 0; + } + if (allfail) { fprintf(stdout, "no offload info available\n"); return 83; } - return dump_offload(rx, tx, sg, tso); + return dump_offload(rx, tx, sg, tso, uso); } static int do_soffload(int fd, struct ifreq *ifr) @@ -1562,6 +1578,17 @@ return 88; } } + if (off_uso_wanted >= 0) { + changed = 1; + eval.cmd = ETHTOOL_SUSO; + eval.data = (off_uso_wanted == 1); + ifr->ifr_data = (caddr_t)&eval; + err = ioctl(fd, SIOCETHTOOL, ifr); + if (err) { + perror("Cannot set device udp large send offload settings"); + return 89; + } + } if (!changed) { fprintf(stdout, "no offload settings changed\n"); } From ravinandan.arakali@neterion.com Thu Jun 2 17:48:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 17:48:52 -0700 (PDT) Received: from linux.site (adsl-67-120-213-161.dsl.sntc01.pacbell.net [67.120.213.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j530mlXq018431 for ; Thu, 2 Jun 2005 17:48:48 -0700 Received: by linux.site (Postfix, from userid 0) id BAB6A7B990; Thu, 2 Jun 2005 17:41:06 -0700 (PDT) To: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com Cc: raghavendra.koushik@neterion.com, ravinandan.arakali@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com From: ravinandan.arakali@neterion.com Subject: [PATCH 2.6.12-rc4] IPv4/IPv6: USO v2, Scatter-gather approach Message-Id: <20050603004106.BAB6A7B990@linux.site> Date: Thu, 2 Jun 2005 17:41:06 -0700 (PDT) X-archive-position: 2007 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Content-Length: 14893 Lines: 444 Hi, Attached below is version 2 of kernel patch for UDP Large send offload feature. This patch uses the "Scatter-Gather" approach. It also incorporates David Miller's comments on the first version. Also, below is a "how-to" on changes required in network drivers to use the USO interface. UDP Large Send Offload (USO) Interface: -------------------------------------- USO is a feature wherein the Linux kernel network stack will offload the IP fragmentation functionality of large UDP datagram to hardware. This will reduce the overhead of stack in fragmenting the large UDP datagram to MTU sized packets. 1) Drivers indicate their capability of USO using dev->features |= NETIF_F_USO | NETIF_F_HW_CSUM | NETIF_F_SG NETIF_F_HW_CSUM is required for USO over ipv6. 2) USO packet will be submitted for transmission using driver xmit routine. USO packet will have a non-zero value for "skb_shinfo(skb)->uso_size" skb_shinfo(skb)->uso_size will indicate the length of data part in each IP fragment going out of the adapter after IP fragmentation by hardware. skb->data will contain MAC/IP/UDP header and skb_shinfo(skb)->frags[] contains the data payload. The skb->ip_summed will be set to CHECKSUM_HW indicating that hardware has to do checksum calculation. Hardware should compute the UDP checksum of complete datagram and also ip header checksum of each fragmented IP packet. For IPV6 the USO provides the fragment identification-id in skb_shinfo(skb)->ip6_frag_id. The adapter should use this ID for generating IPv6 fragments. Signed-off-by: Ananda Raju Signed-off-by: Ravinandan Arakali --- diff -uNr linux-2.6.12-rc4.org/include/linux/ethtool.h linux-2.6.12-rc4/include/linux/ethtool.h --- linux-2.6.12-rc4.org/include/linux/ethtool.h 2005-06-01 19:56:58.000000000 +0545 +++ linux-2.6.12-rc4/include/linux/ethtool.h 2005-06-01 19:51:47.000000000 +0545 @@ -260,6 +260,8 @@ int ethtool_op_set_sg(struct net_device *dev, u32 data); u32 ethtool_op_get_tso(struct net_device *dev); int ethtool_op_set_tso(struct net_device *dev, u32 data); +u32 ethtool_op_get_uso(struct net_device *dev); +int ethtool_op_set_uso(struct net_device *dev, u32 data); /** * ðtool_ops - Alter and report network device settings @@ -289,6 +291,8 @@ * set_sg: Turn scatter-gather on or off * get_tso: Report whether TCP segmentation offload is enabled * set_tso: Turn TCP segmentation offload on or off + * get_uso: Report whether UDP large send offload is enabled + * set_uso: Turn UDP large send offload on or off * self_test: Run specified self-tests * get_strings: Return a set of strings that describe the requested objects * phys_id: Identify the device @@ -353,6 +357,8 @@ void (*get_ethtool_stats)(struct net_device *, struct ethtool_stats *, u64 *); int (*begin)(struct net_device *); void (*complete)(struct net_device *); + u32 (*get_uso)(struct net_device *); + int (*set_uso)(struct net_device *, u32); }; /* CMDs currently supported */ @@ -388,6 +394,8 @@ #define ETHTOOL_GSTATS 0x0000001d /* get NIC-specific statistics */ #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ +#define ETHTOOL_GUSO 0x00000020 /* Get USO enable (ethtool_value) */ +#define ETHTOOL_SUSO 0x00000021 /* Set USO enable (ethtool_value) */ /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET diff -uNr linux-2.6.12-rc4.org/include/linux/netdevice.h linux-2.6.12-rc4/include/linux/netdevice.h --- linux-2.6.12-rc4.org/include/linux/netdevice.h 2005-05-25 17:18:11.000000000 +0545 +++ linux-2.6.12-rc4/include/linux/netdevice.h 2005-06-01 14:33:12.000000000 +0545 @@ -414,6 +414,7 @@ #define NETIF_F_VLAN_CHALLENGED 1024 /* Device cannot handle VLAN packets */ #define NETIF_F_TSO 2048 /* Can offload TCP/IP segmentation */ #define NETIF_F_LLTX 4096 /* LockLess TX */ +#define NETIF_F_USO 8192 /* Can offload UDP Large Send*/ /* Called after device is detached from network. */ void (*uninit)(struct net_device *dev); diff -uNr linux-2.6.12-rc4.org/include/linux/skbuff.h linux-2.6.12-rc4/include/linux/skbuff.h --- linux-2.6.12-rc4.org/include/linux/skbuff.h 2005-05-25 17:18:20.000000000 +0545 +++ linux-2.6.12-rc4/include/linux/skbuff.h 2005-06-01 15:18:44.000000000 +0545 @@ -135,6 +135,8 @@ atomic_t dataref; unsigned int nr_frags; unsigned short tso_size; + unsigned short uso_size; + unsigned int ip6_frag_id; unsigned short tso_segs; struct sk_buff *frag_list; skb_frag_t frags[MAX_SKB_FRAGS]; diff -uNr linux-2.6.12-rc4.org/include/net/sock.h linux-2.6.12-rc4/include/net/sock.h --- linux-2.6.12-rc4.org/include/net/sock.h 2005-05-25 17:18:44.000000000 +0545 +++ linux-2.6.12-rc4/include/net/sock.h 2005-05-25 20:28:14.000000000 +0545 @@ -1296,5 +1296,11 @@ return -ENODEV; } #endif +struct sk_buff *sock_append_data(struct sock *sk, + int getfrag(void *from, char *to, int offset, int len, + int odd, struct sk_buff *skb), + void *from, int length, int transhdrlen, + int hh_len, int fragheaderlen, + unsigned int flags,int *err); #endif /* _SOCK_H */ diff -uNr linux-2.6.12-rc4.org/net/core/dev.c linux-2.6.12-rc4/net/core/dev.c --- linux-2.6.12-rc4.org/net/core/dev.c 2005-06-01 14:35:01.000000000 +0545 +++ linux-2.6.12-rc4/net/core/dev.c 2005-06-01 19:46:03.000000000 +0545 @@ -2793,6 +2793,18 @@ dev->name); dev->features &= ~NETIF_F_TSO; } + if (dev->features & NETIF_F_USO) { + if (!(dev->features & NETIF_F_HW_CSUM)) { + printk("%s: Dropping NETIF_F_USO since no ", dev->name); + printk("NETIF_F_HW_CSUM feature.\n"); + dev->features &= ~NETIF_F_USO; + } + if (!(dev->features & NETIF_F_SG)) { + printk("%s: Dropping NETIF_F_USO since no ", dev->name); + printk("NETIF_F_SG feature.\n"); + dev->features &= ~NETIF_F_USO; + } + } /* * nil rebuild_header routine, diff -uNr linux-2.6.12-rc4.org/net/core/ethtool.c linux-2.6.12-rc4/net/core/ethtool.c --- linux-2.6.12-rc4.org/net/core/ethtool.c 2005-06-01 19:48:31.000000000 +0545 +++ linux-2.6.12-rc4/net/core/ethtool.c 2005-06-01 23:02:39.000000000 +0545 @@ -72,6 +72,21 @@ return 0; } +u32 ethtool_op_get_uso(struct net_device *dev) +{ + return (dev->features & NETIF_F_USO) != 0; +} + +int ethtool_op_set_uso(struct net_device *dev, u32 data) +{ + if (data) + dev->features |= NETIF_F_USO; + else + dev->features &= ~NETIF_F_USO; + + return 0; +} + /* Handlers for each ethtool command */ static int ethtool_get_settings(struct net_device *dev, void __user *useraddr) @@ -460,6 +475,9 @@ err = dev->ethtool_ops->set_tso(dev, 0); if (err) return err; + err = dev->ethtool_ops->set_uso(dev, 0); + if (err) + return err; } return dev->ethtool_ops->set_sg(dev, data); @@ -548,6 +566,39 @@ return dev->ethtool_ops->set_tso(dev, edata.data); } +static int ethtool_get_uso(struct net_device *dev, char __user *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GTSO }; + + if (!dev->ethtool_ops->get_uso) + return -EOPNOTSUPP; + + edata.data = dev->ethtool_ops->get_uso(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_uso(struct net_device *dev, char __user *useraddr) +{ + struct ethtool_value edata; + + if (!dev->ethtool_ops->set_uso) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + if (edata.data && !(dev->features & NETIF_F_SG)) + return -EINVAL; + + if (edata.data && !(dev->features & NETIF_F_HW_CSUM)) + return -EINVAL; + + return dev->ethtool_ops->set_uso(dev, edata.data); +} + static int ethtool_self_test(struct net_device *dev, char __user *useraddr) { struct ethtool_test test; @@ -795,6 +846,12 @@ case ETHTOOL_GSTATS: rc = ethtool_get_stats(dev, useraddr); break; + case ETHTOOL_GUSO: + rc = ethtool_get_uso(dev, useraddr); + break; + case ETHTOOL_SUSO: + rc = ethtool_set_uso(dev, useraddr); + break; default: rc = -EOPNOTSUPP; } @@ -817,3 +874,6 @@ EXPORT_SYMBOL(ethtool_op_set_sg); EXPORT_SYMBOL(ethtool_op_set_tso); EXPORT_SYMBOL(ethtool_op_set_tx_csum); +EXPORT_SYMBOL(ethtool_op_set_uso); +EXPORT_SYMBOL(ethtool_op_get_uso); + diff -uNr linux-2.6.12-rc4.org/net/core/skbuff.c linux-2.6.12-rc4/net/core/skbuff.c --- linux-2.6.12-rc4.org/net/core/skbuff.c 2005-05-25 20:25:35.000000000 +0545 +++ linux-2.6.12-rc4/net/core/skbuff.c 2005-06-01 14:34:27.000000000 +0545 @@ -159,6 +159,8 @@ skb_shinfo(skb)->tso_size = 0; skb_shinfo(skb)->tso_segs = 0; skb_shinfo(skb)->frag_list = NULL; + skb_shinfo(skb)->uso_size = 0; + skb_shinfo(skb)->ip6_frag_id = 0; out: return skb; nodata: diff -uNr linux-2.6.12-rc4.org/net/core/sock.c linux-2.6.12-rc4/net/core/sock.c --- linux-2.6.12-rc4.org/net/core/sock.c 2005-05-25 20:25:47.000000000 +0545 +++ linux-2.6.12-rc4/net/core/sock.c 2005-06-01 19:40:03.000000000 +0545 @@ -1401,6 +1401,102 @@ EXPORT_SYMBOL(proto_unregister); +/* + * sock_append_data - append the user data to a skb, + * sk - sock structure which contains skbs for transmission + * getfrag - The function to be called to get the data from the user. + * from - pointer to user message iov + * length - length of the iov message + * transhdrlen - transport header length + * hh_len - hardware header length + * fragheaderlen - length of the IP header + * flags - iov message flags + * err - Error code returned + * + * This procedure will allocate a skb enough to hold protocol headers and + * append the user data in the fragment part of the skb and add the skb to + * socket write queue + */ +struct sk_buff *sock_append_data(struct sock *sk, + int getfrag(void *from, char *to, int offset, int len, + int odd, struct sk_buff *skb), + void *from, int length, int transhdrlen, + int hh_len, int fragheaderlen, + unsigned int flags,int *err) +{ + struct sk_buff *skb; + int frg_cnt = 0; + skb_frag_t *frag = NULL; + struct page *page = NULL; + int copy, left; + int offset = 0; + + if (skb_queue_len(&sk->sk_write_queue)) { + *err = -EOPNOTSUPP; + return NULL; + } + + skb = sock_alloc_send_skb(sk, + hh_len + fragheaderlen + transhdrlen + 20, + (flags & MSG_DONTWAIT), err); + if (skb == NULL) { + *err = -ENOMEM; + return NULL; + } + /* reserve space for Hardware header */ + skb_reserve(skb, hh_len); + /* create space for UDP/IP header */ + skb_put(skb,fragheaderlen + transhdrlen); + /* initialize network header pointer */ + skb->nh.raw = skb->data; + /* initialize protocol header pointer */ + skb->h.raw = skb->data + fragheaderlen; + skb->ip_summed = CHECKSUM_HW; + skb->csum = 0; + do { + copy = length; + if (frg_cnt >= MAX_SKB_FRAGS) { + *err = -EFAULT; + kfree_skb(skb); + return NULL; + } + page = alloc_pages(sk->sk_allocation, 0); + if (page == NULL) { + *err = -ENOMEM; + kfree_skb(skb); + return NULL; + } + sk->sk_sndmsg_page = page; + sk->sk_sndmsg_off = 0; + skb_fill_page_desc(skb, frg_cnt, page, 0, 0); + skb->truesize += PAGE_SIZE; + atomic_add(PAGE_SIZE, &sk->sk_wmem_alloc); + frg_cnt = skb_shinfo(skb)->nr_frags; + frag = &skb_shinfo(skb)->frags[frg_cnt - 1]; + left = PAGE_SIZE - frag->page_offset; + if (copy > left) + copy = left; + if (getfrag(from, page_address(frag->page)+ + frag->page_offset+frag->size, + offset, copy, 0, skb) < 0) { + *err = -EFAULT; + kfree_skb(skb); + return NULL; + } + sk->sk_sndmsg_off += copy; + frag->size += copy; + skb->len += copy; + skb->data_len += copy; + offset += copy; + length -= copy; + page = NULL; + } while (length > 0); + __skb_queue_tail(&sk->sk_write_queue, skb); + *err = 0; + return skb; +} +EXPORT_SYMBOL(sock_append_data); + #ifdef CONFIG_PROC_FS static inline struct proto *__proto_head(void) { diff -uNr linux-2.6.12-rc4.org/net/ipv4/ip_output.c linux-2.6.12-rc4/net/ipv4/ip_output.c --- linux-2.6.12-rc4.org/net/ipv4/ip_output.c 2005-05-25 20:26:07.000000000 +0545 +++ linux-2.6.12-rc4/net/ipv4/ip_output.c 2005-06-02 22:04:59.000000000 +0545 @@ -291,7 +291,8 @@ { IP_INC_STATS(IPSTATS_MIB_OUTREQUESTS); - if (skb->len > dst_mtu(skb->dst) && !skb_shinfo(skb)->tso_size) + if (skb->len > dst_mtu(skb->dst) && + !(skb_shinfo(skb)->uso_size || skb_shinfo(skb)->tso_size)) return ip_fragment(skb, ip_finish_output); else return ip_finish_output(skb); @@ -789,6 +790,28 @@ inet->cork.length += length; + if (((length > mtu) && (sk->sk_protocol == IPPROTO_UDP)) && + (rt->u.dst.dev->features & NETIF_F_USO)) { + /* There is support for UDP large send offload by network + * device, so create one single skb packet containing complete + * udp datagram + */ + skb = sock_append_data(sk, getfrag, from, + (length - transhdrlen), transhdrlen, + hh_len, fragheaderlen, flags, &err); + if (skb != NULL) { + /* specify the length of each IP datagram fragment*/ + skb_shinfo(skb)->uso_size = (mtu - fragheaderlen); + return 0; + } else if (err == -EOPNOTSUPP) { + /* There is not enough support do UPD LSO, + * so follow normal path + */ + err = 0; + } else + goto error; + } + /* So, what's going on in the loop below? * * We use calculated fragment length to generate chained skb, diff -uNr linux-2.6.12-rc4.org/net/ipv6/ip6_output.c linux-2.6.12-rc4/net/ipv6/ip6_output.c --- linux-2.6.12-rc4.org/net/ipv6/ip6_output.c 2005-05-25 20:26:17.000000000 +0545 +++ linux-2.6.12-rc4/net/ipv6/ip6_output.c 2005-06-02 22:05:24.000000000 +0545 @@ -147,7 +147,8 @@ int ip6_output(struct sk_buff *skb) { - if (skb->len > dst_mtu(skb->dst) || dst_allfrag(skb->dst)) + if ((skb->len > dst_mtu(skb->dst) && !skb_shinfo(skb)->uso_size) || + dst_allfrag(skb->dst)) return ip6_fragment(skb, ip6_output2); else return ip6_output2(skb); @@ -898,6 +899,33 @@ */ inet->cork.length += length; + if (((length > mtu) && (sk->sk_protocol == IPPROTO_UDP)) && + (rt->u.dst.dev->features & NETIF_F_USO)) { + + /* There is support for UDP large send offload by network + * device, so create one single skb packet containing complete + * udp datagram + */ + skb = sock_append_data(sk, getfrag, from, + (length - transhdrlen), transhdrlen, + hh_len, fragheaderlen, flags, &err); + if (skb != NULL) { + struct frag_hdr fhdr; + + /* specify the length of each IP datagram fragment*/ + skb_shinfo(skb)->uso_size = (mtu - fragheaderlen - + sizeof(struct frag_hdr)); + ipv6_select_ident(skb, &fhdr); + skb_shinfo(skb)->ip6_frag_id = fhdr.identification; + return 0; + } else if (err == -EOPNOTSUPP){ + /* There is not enough support for UDP LSO, + * so follow normal path + */ + err = 0; + } else + goto error; + } if ((skb = skb_peek_tail(&sk->sk_write_queue)) == NULL) goto alloc_new_skb; From ravinandan.arakali@neterion.com Thu Jun 2 17:51:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 17:51:32 -0700 (PDT) Received: from linux.site (adsl-67-120-213-161.dsl.sntc01.pacbell.net [67.120.213.161]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j530pTXq018773 for ; Thu, 2 Jun 2005 17:51:29 -0700 Received: by linux.site (Postfix, from userid 0) id 41BFB7B990; Thu, 2 Jun 2005 17:43:51 -0700 (PDT) To: davem@davemloft.net, jgarzik@pobox.com, netdev@oss.sgi.com Cc: raghavendra.koushik@neterion.com, ravinandan.arakali@neterion.com, leonid.grossman@neterion.com, ananda.raju@neterion.com, rapuru.sriram@neterion.com From: ravinandan.arakali@neterion.com Subject: [PATCH 2.6.12-rc4] IPv4/IPv6: USO v2, fragment list approach Message-Id: <20050603004351.41BFB7B990@linux.site> Date: Thu, 2 Jun 2005 17:43:51 -0700 (PDT) X-archive-position: 2008 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ravinandan.arakali@neterion.com Precedence: bulk X-list: netdev Content-Length: 11495 Lines: 322 Hi, Attached below is version 2 of kernel patch for UDP Large send offload feature. This patch uses the "fragment list" approach. It also incorporates David Miller's comments on the first version. Also, below is a "how-to" on changes required in network drivers to use the USO interface. UDP Large Send Offload (USO) Interface: --------------------------------------- USO is a feature wherein the Linux kernel network stack will offload the IP fragmentation functionality of large UDP datagram to hardware. This will reduce the overhead of stack in fragmenting the large UDP datagram to MTU sized packets. 1) Drivers indicate their capability of USO using dev->features |= NETIF_F_USO | NETIF_F_HW_CSUM | NETIF_F_FRAGLIST NETIF_F_HW_CSUM is required for USO over IPv6. 2) USO packet will be submitted for transmission using driver xmit routine. USO packet will have a non zero value for "skb_shinfo(skb)->uso_size" skb_shinfo(skb)->uso_size indicates the length of data part in each IP fragment going out of the adapter after IP fragmentation by hardware. skb->data and skb_shinfo(skb)->frag_list will contain complete large UDP datagram. The driver is required to traverse each skb in skb_shinfo(skb)->frag_list to get complete UDP packet. The skb->ip_summed will be set to CHECKSUM_HW indicating that hardware has to perform checksum calculation. Hardware should compute the UDP checksum of complete UDP datagram and also ip header checksum of each fragmented IP packet. For IPV6 the USO provides the fragment identification id in skb_shinfo(skb)->ip6_frag_id. The adapter should use this ID for generating IPv6 fragments. Signed-off-by: Ananda Raju Signed-off-by: Ravinandan Arakali --- diff -uNr linux-2.6.12-rc4.org/include/linux/ethtool.h linux-2.6.12-rc4/include/linux/ethtool.h --- linux-2.6.12-rc4.org/include/linux/ethtool.h 2005-06-02 16:55:51.000000000 +0545 +++ linux-2.6.12-rc4/include/linux/ethtool.h 2005-06-02 16:56:46.000000000 +0545 @@ -260,6 +260,8 @@ int ethtool_op_set_sg(struct net_device *dev, u32 data); u32 ethtool_op_get_tso(struct net_device *dev); int ethtool_op_set_tso(struct net_device *dev, u32 data); +u32 ethtool_op_get_uso(struct net_device *dev); +int ethtool_op_set_uso(struct net_device *dev, u32 data); /** * ðtool_ops - Alter and report network device settings @@ -289,6 +291,8 @@ * set_sg: Turn scatter-gather on or off * get_tso: Report whether TCP segmentation offload is enabled * set_tso: Turn TCP segmentation offload on or off + * get_uso: Report whether UDP large send offload is enabled + * set_uso: Turn UDP large send offload on or off * self_test: Run specified self-tests * get_strings: Return a set of strings that describe the requested objects * phys_id: Identify the device @@ -353,6 +357,8 @@ void (*get_ethtool_stats)(struct net_device *, struct ethtool_stats *, u64 *); int (*begin)(struct net_device *); void (*complete)(struct net_device *); + u32 (*get_uso)(struct net_device *); + int (*set_uso)(struct net_device *, u32); }; /* CMDs currently supported */ @@ -388,6 +394,8 @@ #define ETHTOOL_GSTATS 0x0000001d /* get NIC-specific statistics */ #define ETHTOOL_GTSO 0x0000001e /* Get TSO enable (ethtool_value) */ #define ETHTOOL_STSO 0x0000001f /* Set TSO enable (ethtool_value) */ +#define ETHTOOL_GUSO 0x00000020 /* Get USO enable (ethtool_value) */ +#define ETHTOOL_SUSO 0x00000021 /* Set USO enable (ethtool_value) */ /* compatibility with older code */ #define SPARC_ETH_GSET ETHTOOL_GSET diff -uNr linux-2.6.12-rc4.org/include/linux/netdevice.h linux-2.6.12-rc4/include/linux/netdevice.h --- linux-2.6.12-rc4.org/include/linux/netdevice.h 2005-05-27 23:22:46.000000000 +0545 +++ linux-2.6.12-rc4/include/linux/netdevice.h 2005-05-31 10:02:02.000000000 +0545 @@ -414,6 +414,7 @@ #define NETIF_F_VLAN_CHALLENGED 1024 /* Device cannot handle VLAN packets */ #define NETIF_F_TSO 2048 /* Can offload TCP/IP segmentation */ #define NETIF_F_LLTX 4096 /* LockLess TX */ +#define NETIF_F_USO 8192 /* Can offload UDP Large Send*/ /* Called after device is detached from network. */ void (*uninit)(struct net_device *dev); diff -uNr linux-2.6.12-rc4.org/include/linux/skbuff.h linux-2.6.12-rc4/include/linux/skbuff.h --- linux-2.6.12-rc4.org/include/linux/skbuff.h 2005-05-27 23:22:46.000000000 +0545 +++ linux-2.6.12-rc4/include/linux/skbuff.h 2005-06-02 20:27:43.000000000 +0545 @@ -136,6 +136,8 @@ unsigned int nr_frags; unsigned short tso_size; unsigned short tso_segs; + unsigned short uso_size; + unsigned int ip6_frag_id; struct sk_buff *frag_list; skb_frag_t frags[MAX_SKB_FRAGS]; }; diff -uNr linux-2.6.12-rc4.org/net/core/dev.c linux-2.6.12-rc4/net/core/dev.c --- linux-2.6.12-rc4.org/net/core/dev.c 2005-05-28 01:49:18.000000000 +0545 +++ linux-2.6.12-rc4/net/core/dev.c 2005-05-31 22:57:22.000000000 +0545 @@ -2793,6 +2793,18 @@ dev->name); dev->features &= ~NETIF_F_TSO; } + if (dev->features & NETIF_F_USO) { + if(!(dev->features & NETIF_F_FRAGLIST)) { + printk("%s: Dropping NETIF_F_USO since no ", dev->name); + printk("NETIF_F_FRAGLIST feature.\n"); + dev->features &= ~NETIF_F_USO; + } + if(!(dev->features & NETIF_F_HW_CSUM)) { + printk("%s: Dropping NETIF_F_USO since no ", dev->name); + printk("NETIF_F_HW_CSUM feature.\n"); + dev->features &= ~NETIF_F_USO; + } + } /* * nil rebuild_header routine, diff -uNr linux-2.6.12-rc4.org/net/core/ethtool.c linux-2.6.12-rc4/net/core/ethtool.c --- linux-2.6.12-rc4.org/net/core/ethtool.c 2005-06-02 16:55:32.000000000 +0545 +++ linux-2.6.12-rc4/net/core/ethtool.c 2005-06-02 21:53:16.000000000 +0545 @@ -72,6 +72,21 @@ return 0; } +u32 ethtool_op_get_uso(struct net_device *dev) +{ + return (dev->features & NETIF_F_USO) != 0; +} + +int ethtool_op_set_uso(struct net_device *dev, u32 data) +{ + if (data) + dev->features |= NETIF_F_USO; + else + dev->features &= ~NETIF_F_USO; + + return 0; +} + /* Handlers for each ethtool command */ static int ethtool_get_settings(struct net_device *dev, void __user *useraddr) @@ -548,6 +563,39 @@ return dev->ethtool_ops->set_tso(dev, edata.data); } +static int ethtool_get_uso(struct net_device *dev, char __user *useraddr) +{ + struct ethtool_value edata = { ETHTOOL_GTSO }; + + if (!dev->ethtool_ops->get_uso) + return -EOPNOTSUPP; + + edata.data = dev->ethtool_ops->get_uso(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; +} + +static int ethtool_set_uso(struct net_device *dev, char __user *useraddr) +{ + struct ethtool_value edata; + + if (!dev->ethtool_ops->set_uso) + return -EOPNOTSUPP; + + if (copy_from_user(&edata, useraddr, sizeof(edata))) + return -EFAULT; + + if (edata.data && !(dev->features & NETIF_F_FRAGLIST)) + return -EINVAL; + + if (edata.data && !(dev->features & NETIF_F_HW_CSUM)) + return -EINVAL; + + return dev->ethtool_ops->set_uso(dev, edata.data); +} + static int ethtool_self_test(struct net_device *dev, char __user *useraddr) { struct ethtool_test test; @@ -795,6 +843,12 @@ case ETHTOOL_GSTATS: rc = ethtool_get_stats(dev, useraddr); break; + case ETHTOOL_GUSO: + rc = ethtool_get_uso(dev, useraddr); + break; + case ETHTOOL_SUSO: + rc = ethtool_set_uso(dev, useraddr); + break; default: rc = -EOPNOTSUPP; } @@ -817,3 +871,6 @@ EXPORT_SYMBOL(ethtool_op_set_sg); EXPORT_SYMBOL(ethtool_op_set_tso); EXPORT_SYMBOL(ethtool_op_set_tx_csum); +EXPORT_SYMBOL(ethtool_op_set_uso); +EXPORT_SYMBOL(ethtool_op_get_uso); + diff -uNr linux-2.6.12-rc4.org/net/core/skbuff.c linux-2.6.12-rc4/net/core/skbuff.c --- linux-2.6.12-rc4.org/net/core/skbuff.c 2005-05-27 23:22:46.000000000 +0545 +++ linux-2.6.12-rc4/net/core/skbuff.c 2005-06-02 20:27:27.000000000 +0545 @@ -159,6 +159,8 @@ skb_shinfo(skb)->tso_size = 0; skb_shinfo(skb)->tso_segs = 0; skb_shinfo(skb)->frag_list = NULL; + skb_shinfo(skb)->ip6_frag_id = 0; + skb_shinfo(skb)->uso_size = 0; out: return skb; nodata: diff -uNr linux-2.6.12-rc4.org/net/ipv4/ip_output.c linux-2.6.12-rc4/net/ipv4/ip_output.c --- linux-2.6.12-rc4.org/net/ipv4/ip_output.c 2005-05-27 23:22:46.000000000 +0545 +++ linux-2.6.12-rc4/net/ipv4/ip_output.c 2005-05-31 15:55:39.000000000 +0545 @@ -291,7 +291,8 @@ { IP_INC_STATS(IPSTATS_MIB_OUTREQUESTS); - if (skb->len > dst_mtu(skb->dst) && !skb_shinfo(skb)->tso_size) + if (skb->len > dst_mtu(skb->dst) && + !(skb_shinfo(skb)->tso_size || skb_shinfo(skb)->uso_size)) return ip_fragment(skb, ip_finish_output); else return ip_finish_output(skb); @@ -768,7 +769,6 @@ mtu = inet->cork.fragsize; } hh_len = LL_RESERVED_SPACE(rt->u.dst.dev); - fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0); maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen; @@ -864,6 +864,12 @@ skb->ip_summed = csummode; skb->csum = 0; skb_reserve(skb, hh_len); + if ((!offset) && (length > mtu) && + (sk->sk_protocol == IPPROTO_UDP) && + (rt->u.dst.dev->features & NETIF_F_USO)) { + skb_shinfo(skb)->uso_size = mtu - fragheaderlen; + skb->ip_summed = CHECKSUM_HW; + } /* * Find where to start putting bytes. diff -uNr linux-2.6.12-rc4.org/net/ipv4/udp.c linux-2.6.12-rc4/net/ipv4/udp.c --- linux-2.6.12-rc4.org/net/ipv4/udp.c 2005-05-27 23:23:55.000000000 +0545 +++ linux-2.6.12-rc4/net/ipv4/udp.c 2005-05-31 21:14:44.000000000 +0545 @@ -424,9 +424,10 @@ goto send; } - if (skb_queue_len(&sk->sk_write_queue) == 1) { + if ((skb_queue_len(&sk->sk_write_queue) == 1) || + (skb_shinfo(skb)->uso_size)) { /* - * Only one fragment on the socket. + * Only one fragment on the socket or it is udp lso skb. */ if (skb->ip_summed == CHECKSUM_HW) { skb->csum = offsetof(struct udphdr, check); diff -uNr linux-2.6.12-rc4.org/net/ipv6/ip6_output.c linux-2.6.12-rc4/net/ipv6/ip6_output.c --- linux-2.6.12-rc4.org/net/ipv6/ip6_output.c 2005-05-27 23:22:46.000000000 +0545 +++ linux-2.6.12-rc4/net/ipv6/ip6_output.c 2005-06-02 20:27:55.000000000 +0545 @@ -147,7 +147,8 @@ int ip6_output(struct sk_buff *skb) { - if (skb->len > dst_mtu(skb->dst) || dst_allfrag(skb->dst)) + if ((skb->len > dst_mtu(skb->dst) || dst_allfrag(skb->dst)) && + !skb_shinfo(skb)->uso_size) return ip6_fragment(skb, ip6_output2); else return ip6_output2(skb); @@ -977,6 +978,19 @@ skb->csum = 0; /* reserve for fragmentation */ skb_reserve(skb, hh_len+sizeof(struct frag_hdr)); + if ((!offset) && (length > mtu) && + (sk->sk_protocol == IPPROTO_UDP) && + (rt->u.dst.dev->features & NETIF_F_USO)) { + struct frag_hdr fhdr; + + skb_shinfo(skb)->uso_size = + (mtu - fragheaderlen - + sizeof(struct frag_hdr)); + skb->ip_summed = CHECKSUM_HW; + ipv6_select_ident(skb, &fhdr); + skb_shinfo(skb)->ip6_frag_id = + fhdr.identification; + } /* * Find where to start putting bytes diff -uNr linux-2.6.12-rc4.org/net/ipv6/udp.c linux-2.6.12-rc4/net/ipv6/udp.c --- linux-2.6.12-rc4.org/net/ipv6/udp.c 2005-05-27 23:24:12.000000000 +0545 +++ linux-2.6.12-rc4/net/ipv6/udp.c 2005-05-31 17:32:31.000000000 +0545 @@ -590,7 +590,8 @@ goto send; } - if (skb_queue_len(&sk->sk_write_queue) == 1) { + if ((skb_queue_len(&sk->sk_write_queue) == 1) || + (skb_shinfo(skb)->uso_size)) { skb->csum = csum_partial((char *)uh, sizeof(struct udphdr), skb->csum); uh->check = csum_ipv6_magic(&fl->fl6_src, From tgraf@suug.ch Thu Jun 2 18:01:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 18:01:42 -0700 (PDT) Received: from postel.suug.ch (postel.suug.ch [195.134.158.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5311dXq021235 for ; Thu, 2 Jun 2005 18:01:39 -0700 Received: by postel.suug.ch (Postfix, from userid 10001) id 3FBB51C0EF; Fri, 3 Jun 2005 03:00:59 +0200 (CEST) Date: Fri, 3 Jun 2005 03:00:59 +0200 From: Thomas Graf To: jamal Cc: "David S. Miller" , netdev Subject: Re: PATCH: ioctl send PID in netlink events Message-ID: <20050603010059.GU15391@postel.suug.ch> References: <1117720349.6050.59.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117720349.6050.59.camel@localhost.localdomain> X-archive-position: 2010 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tgraf@suug.ch Precedence: bulk X-list: netdev Content-Length: 1453 Lines: 48 > Index: net/ipv4/devinet.c > =================================================================== > --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/devinet.c (mode:100644) > +++ uncommitted/net/ipv4/devinet.c (mode:100644) > @@ -236,6 +236,7 @@ > struct in_ifaddr *promote = NULL; > struct in_ifaddr *ifa1 = *ifap; > > + printk("inet_del_ifa: pid %d\n",current->pid); > ASSERT_RTNL(); > > /* 1. Deleting primary ifaddr forces deletion all secondaries > @@ -305,6 +306,7 @@ > > ASSERT_RTNL(); > > + printk("inet_insert_ifa: pid %d\n",current->pid); > if (!ifa->ifa_local) { > inet_free_ifa(ifa); > return 0; Don't you want to remove these? > Index: net/ipv4/fib_semantics.c > =================================================================== > --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/fib_semantics.c (mode:100644) > +++ uncommitted/net/ipv4/fib_semantics.c (mode:100644) > @@ -276,7 +276,7 @@ > struct nlmsghdr *n, struct netlink_skb_parms *req) > { > struct sk_buff *skb; > - u32 pid = req ? req->pid : 0; > + u32 pid = req ? req->pid : n->nlmsg_pid; > int size = NLMSG_SPACE(sizeof(struct rtmsg)+256); > > skb = alloc_skb(size, GFP_KERNEL); > @@ -1035,7 +1035,7 @@ > } > > nl->nlmsg_flags = NLM_F_REQUEST; > - nl->nlmsg_pid = 0; > + nl->nlmsg_pid = current->pid; > nl->nlmsg_seq = 0; > nl->nlmsg_len = NLMSG_LENGTH(sizeof(*rtm)); > if (cmd == SIOCDELRT) { Neat ;-> From hadi@cyberus.ca Thu Jun 2 18:38:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 18:38:44 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j531cfXq023346 for ; Thu, 2 Jun 2005 18:38:41 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1De18A-0000Ng-QE for netdev@oss.sgi.com; Thu, 02 Jun 2005 21:37:50 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1De181-0000zG-1e; Thu, 02 Jun 2005 21:37:41 -0400 Subject: Re: PATCH: ioctl send PID in netlink events From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev In-Reply-To: <20050603010059.GU15391@postel.suug.ch> References: <1117720349.6050.59.camel@localhost.localdomain> <20050603010059.GU15391@postel.suug.ch> Content-Type: text/plain Organization: unknown Date: Thu, 02 Jun 2005 21:37:35 -0400 Message-Id: <1117762655.6095.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 2011 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1809 Lines: 62 On Fri, 2005-03-06 at 03:00 +0200, Thomas Graf wrote: > > Index: net/ipv4/devinet.c > > =================================================================== > > --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/devinet.c (mode:100644) > > +++ uncommitted/net/ipv4/devinet.c (mode:100644) > > @@ -236,6 +236,7 @@ > > struct in_ifaddr *promote = NULL; > > struct in_ifaddr *ifa1 = *ifap; > > > > + printk("inet_del_ifa: pid %d\n",current->pid); > > ASSERT_RTNL(); > > > > /* 1. Deleting primary ifaddr forces deletion all secondaries > > @@ -305,6 +306,7 @@ > > > > ASSERT_RTNL(); > > > > + printk("inet_insert_ifa: pid %d\n",current->pid); > > if (!ifa->ifa_local) { > > inet_free_ifa(ifa); > > return 0; > > Don't you want to remove these? > > Yes, how did those get there? ;-> > > Index: net/ipv4/fib_semantics.c > > =================================================================== > > --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/fib_semantics.c (mode:100644) > > +++ uncommitted/net/ipv4/fib_semantics.c (mode:100644) > > @@ -276,7 +276,7 @@ > > struct nlmsghdr *n, struct netlink_skb_parms *req) > > { > > struct sk_buff *skb; > > - u32 pid = req ? req->pid : 0; > > + u32 pid = req ? req->pid : n->nlmsg_pid; > > int size = NLMSG_SPACE(sizeof(struct rtmsg)+256); > > > > skb = alloc_skb(size, GFP_KERNEL); > > @@ -1035,7 +1035,7 @@ > > } > > > > nl->nlmsg_flags = NLM_F_REQUEST; > > - nl->nlmsg_pid = 0; > > + nl->nlmsg_pid = current->pid; > > nl->nlmsg_seq = 0; > > nl->nlmsg_len = NLMSG_LENGTH(sizeof(*rtm)); > > if (cmd == SIOCDELRT) { > > Neat ;-> The second one could probably use the new macros. Maybe i will wait until Dave puts this in his tree and send a small change; else you could send it. cheers, jamal From hadi@cyberus.ca Thu Jun 2 19:37:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 19:37:29 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j532bMXq027358 for ; Thu, 2 Jun 2005 19:37:27 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1De22u-00056A-E8 for netdev@oss.sgi.com; Thu, 02 Jun 2005 22:36:28 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1De22p-0002eo-L3; Thu, 02 Jun 2005 22:36:23 -0400 Subject: Re: [PATCH] shaper.c: fix locking From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: hch@lst.de, netdev@oss.sgi.com In-Reply-To: <20050602.163628.01205145.davem@davemloft.net> References: <20050527115450.GA19469@lst.de> <20050531.144114.78710204.davem@davemloft.net> <20050601052149.GA11935@lst.de> <20050602.163628.01205145.davem@davemloft.net> Content-Type: text/plain Organization: unknown Date: Thu, 02 Jun 2005 22:36:17 -0400 Message-Id: <1117766177.6095.51.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 2013 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 249 Lines: 10 On Thu, 2005-02-06 at 16:36 -0700, David S. Miller wrote: > Fair enough, patch applied. If this driver breaks as a result of > these changes, you get to keep the pieces ok? :-) The question is anyone really using this driver? ;-> cheers, jamal From hadi@cyberus.ca Thu Jun 2 19:33:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 19:33:45 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j532XfXq027002 for ; Thu, 2 Jun 2005 19:33:41 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1De1zI-0000o5-El for netdev@oss.sgi.com; Thu, 02 Jun 2005 22:32:44 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1De1zG-00029R-2M; Thu, 02 Jun 2005 22:32:42 -0400 Subject: Re: RFC: NAPI packet weighting patch From: jamal Reply-To: hadi@cyberus.ca To: "David S. Miller" Cc: john.ronciak@intel.com, jdmason@us.ibm.com, shemminger@osdl.org, mitch.a.williams@intel.com, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com In-Reply-To: <20050602.171812.48807872.davem@davemloft.net> References: <468F3FDA28AA87429AD807992E22D07E0450BFDB@orsmsx408> <20050602.171812.48807872.davem@davemloft.net> Content-Type: text/plain Organization: unknown Date: Thu, 02 Jun 2005 22:32:33 -0400 Message-Id: <1117765954.6095.49.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 2012 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2544 Lines: 54 On Thu, 2005-02-06 at 17:18 -0700, David S. Miller wrote: > From: "Ronciak, John" > Date: Thu, 2 Jun 2005 17:11:20 -0700 > > > I like this idea as well but I do an issue with it. How would this > > stack code find out that the weight is too high and pacekts are being > > dropped (not being polled fast enough)? It would have to check the > > controller stats to see the error count increasing for some period. I'm > > not sure this is workable unless we have some sort of feedback which the > > driver could send up (or set) saying that this is happening and the > > dynamic weight code could take into acount. > > What more do you need other than checking the statistics counter? The > drop statistics (the ones we care about) are incremented in real time > by the ->poll() code, so it's not like we have to trigger some > asynchronous event to get a current version of the number. I am reading through all the emails and I think either the problem is not being clearly stated or not understood. I was going to say "or i am on crack "- but I know i am clean ;-> Heres what i think i saw as a flow of events: Someone posted a theory that if you happen to reduce the weight (iirc the reduction was via a shift) then the DRR would give less CPU time cycle to the driver - Whats the big suprise there? thats DRR design intent. Stephen has a patch which allows people to reduce the weight. DRR provides fairness. If you have 10 NICs coming at different wire rates, the weights provide a fairness quota without caring about what those speeds are. So it doesnt make any sense IMO to have the weight based on what the NIC speed is. Infact i claim it is _nonsense_. You dont need to factor speed. And the claim that DRR is not real world is blasphemous. Having said that: I have a feeling that issue which is which is being waded around is the amount that the softirq chews in the CPU (unfortunately a well known issue) and to some extent the packet flow a specific driver chews depending on the path it takes. In other words, for DRR algorithm to enhance the fairness it should consider not only fairness in the amounts of packets the driver injects into the system but also the amount of CPU that driver chews. At the moment we lump all drivers together as far as the CPU cycles are concerned. If we could narrow it down to this, then i think there is something that could lead to meaningful discussion. This, however, does not eradicate the need for DRR and is absolutely not driver specific. cheers, jamal From raghunathan.venkatesan@wipro.com Thu Jun 2 20:03:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 20:03:05 -0700 (PDT) Received: from wip-ec-wd.wipro.com (wip-ec-wd.wipro.com [203.101.113.39]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53331Xq029634 for ; Thu, 2 Jun 2005 20:03:01 -0700 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id B83EC205E8; Fri, 3 Jun 2005 08:23:02 +0530 (IST) Received: from blr-ec-bh01.wipro.com (unknown [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 9C493205E5; Fri, 3 Jun 2005 08:23:02 +0530 (IST) Received: from chn-snr-bh2.wipro.com ([10.145.50.92]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 08:31:47 +0530 Received: from CHN-SNR-MBX01.wipro.com ([10.145.50.181]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Jun 2005 08:32:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Unable to handle kernel paging request at virtual address 04000460 Date: Fri, 3 Jun 2005 08:28:34 +0530 Message-ID: <438662DA48DCAA41B1DF648BD4BD76C0E98682@CHN-SNR-MBX01.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unable to handle kernel paging request at virtual address 04000460 Thread-Index: AcVnmr7o+HCu/Cf9S06Mjf+yNyDZmwATUH0g From: To: Cc: , , , X-OriginalArrivalTime: 03 Jun 2005 03:02:04.0645 (UTC) FILETIME=[9EEEC950:01C567E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j53331Xq029634 X-archive-position: 2014 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: raghunathan.venkatesan@wipro.com Precedence: bulk X-list: netdev Content-Length: 1431 Lines: 40 Hi Stephen, I appreciate you response. We'll get deeper into the problem after turning on these debugs. Thanks, Raghu -----Original Message----- From: Stephen Hemminger [mailto:shemminger@osdl.org] Sent: Thursday, June 02, 2005 11:14 PM To: Raghunathan Venkatesan (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS) Cc: davem@davemloft.net; linux-net@vger.kernel.org; netdev@oss.sgi.com; linux@der-keiler.de Subject: Re: Unable to handle kernel paging request at virtual address 04000460 On Thu, 2 Jun 2005 09:20:21 +0530 wrote: > Hi David, > I understand that the linux community may not be able to debug it for > me. All I require is if people have seen similar problems (the > problems we face are w.r.t to kfree_skb and skb_drop_fraglist crashing > due to some reason, which could be a Memory Management issue or some > thing we are not aware of), then let us know the patches, so that we > can try them out here. Turn on Debug memory allocations, spinlock debugging, sleep-inside-spinlock checking, and preempt, it will help your debugging. If you are not building your own kernel from source learn how. You are probably freeing memory twice, or not doing ref counting properly or other locking issues. Since it is your code, good luck debugging it, if you want the community help it needs to be open source code that is available for download or be in the kernel.org kernel. From hadi@cyberus.ca Thu Jun 2 20:34:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 20:34:02 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j533XxXq002309 for ; Thu, 2 Jun 2005 20:33:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1De2vl-0007ca-IK for netdev@oss.sgi.com; Thu, 02 Jun 2005 23:33:09 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1De2vg-0004O7-AG; Thu, 02 Jun 2005 23:33:04 -0400 Subject: Re: PATCH: ioctl send PID in netlink events From: jamal Reply-To: hadi@cyberus.ca To: Thomas Graf Cc: "David S. Miller" , netdev In-Reply-To: <1117762655.6095.3.camel@localhost.localdomain> References: <1117720349.6050.59.camel@localhost.localdomain> <20050603010059.GU15391@postel.suug.ch> <1117762655.6095.3.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-Ufypw+g9dyMzRlXKv19C" Organization: unknown Date: Thu, 02 Jun 2005 23:32:55 -0400 Message-Id: <1117769575.6095.91.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-archive-position: 2015 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3665 Lines: 113 --=-Ufypw+g9dyMzRlXKv19C Content-Type: text/plain Content-Transfer-Encoding: 7bit Dave, If you havent applied that patch to net-2.6.13 heres one that removes those extrenous printks. On Thu, 2005-02-06 at 21:37 -0400, jamal wrote: > The second one could probably use the new macros. > Maybe i will wait until Dave puts this in his tree and send a small > change; else you could send it. > Actually cant be done, sorry i lied ;-> cheers, jamal --=-Ufypw+g9dyMzRlXKv19C Content-Disposition: attachment; filename=ifconf-2 Content-Type: text/plain; name=ifconf-2; charset=utf-8 Content-Transfer-Encoding: 7bit net/core/rtnetlink.c: needs update net/ipv4/devinet.c: needs update net/ipv4/fib_semantics.c: needs update net/ipv6/addrconf.c: needs update Index: net/core/rtnetlink.c =================================================================== --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/core/rtnetlink.c (mode:100644) +++ uncommitted/net/core/rtnetlink.c (mode:100644) @@ -452,7 +452,7 @@ if (!skb) return; - if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change, 0) < 0) { + if (rtnetlink_fill_ifinfo(skb, dev, type, current->pid, 0, change, 0) < 0) { kfree_skb(skb); return; } Index: net/ipv4/devinet.c =================================================================== --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/devinet.c (mode:100644) +++ uncommitted/net/ipv4/devinet.c (mode:100644) @@ -1112,7 +1112,7 @@ if (!skb) netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, ENOBUFS); - else if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { + else if (inet_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, EINVAL); } else { Index: net/ipv4/fib_semantics.c =================================================================== --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv4/fib_semantics.c (mode:100644) +++ uncommitted/net/ipv4/fib_semantics.c (mode:100644) @@ -276,7 +276,7 @@ struct nlmsghdr *n, struct netlink_skb_parms *req) { struct sk_buff *skb; - u32 pid = req ? req->pid : 0; + u32 pid = req ? req->pid : n->nlmsg_pid; int size = NLMSG_SPACE(sizeof(struct rtmsg)+256); skb = alloc_skb(size, GFP_KERNEL); @@ -1035,7 +1035,7 @@ } nl->nlmsg_flags = NLM_F_REQUEST; - nl->nlmsg_pid = 0; + nl->nlmsg_pid = current->pid; nl->nlmsg_seq = 0; nl->nlmsg_len = NLMSG_LENGTH(sizeof(*rtm)); if (cmd == SIOCDELRT) { Index: net/ipv6/addrconf.c =================================================================== --- e4f7366a04d973a42a948d3b4175d66e9adf143e/net/ipv6/addrconf.c (mode:100644) +++ uncommitted/net/ipv6/addrconf.c (mode:100644) @@ -2872,7 +2872,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, ENOBUFS); return; } - if (inet6_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) { + if (inet6_fill_ifaddr(skb, ifa, current->pid, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, EINVAL); return; @@ -3007,7 +3007,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, ENOBUFS); return; } - if (inet6_fill_ifinfo(skb, idev, 0, 0, event, 0) < 0) { + if (inet6_fill_ifinfo(skb, idev, current->pid, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, EINVAL); return; @@ -3064,7 +3064,7 @@ netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, ENOBUFS); return; } - if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event, 0) < 0) { + if (inet6_fill_prefix(skb, idev, pinfo, current->pid, 0, event, 0) < 0) { kfree_skb(skb); netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, EINVAL); return; --=-Ufypw+g9dyMzRlXKv19C-- From davem@davemloft.net Thu Jun 2 22:10:01 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 22:10:03 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j535A1Xq007191 for ; Thu, 2 Jun 2005 22:10:01 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1De4QW-0002C8-6G; Thu, 02 Jun 2005 22:09:00 -0700 Date: Thu, 02 Jun 2005 22:09:00 -0700 (PDT) Message-Id: <20050602.220900.92343575.davem@davemloft.net> To: hadi@cyberus.ca Cc: tgraf@suug.ch, netdev@oss.sgi.com Subject: Re: PATCH: ioctl send PID in netlink events From: "David S. Miller" In-Reply-To: <1117769575.6095.91.camel@localhost.localdomain> References: <20050603010059.GU15391@postel.suug.ch> <1117762655.6095.3.camel@localhost.localdomain> <1117769575.6095.91.camel@localhost.localdomain> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2017 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 192 Lines: 7 From: jamal Date: Thu, 02 Jun 2005 23:32:55 -0400 > If you havent applied that patch to net-2.6.13 heres one that removes > those extrenous printks. Applied, thanks Jamal. From davem@davemloft.net Thu Jun 2 22:12:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 22:12:21 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j535CIXq007864 for ; Thu, 2 Jun 2005 22:12:18 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1De4Sm-0002Dl-1U; Thu, 02 Jun 2005 22:11:20 -0700 Date: Thu, 02 Jun 2005 22:11:19 -0700 (PDT) Message-Id: <20050602.221119.105431518.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: [SCTP] Replace spin_lock_irqsave with spin_lock_bh From: "David S. Miller" In-Reply-To: <20050602095459.GA26638@gondor.apana.org.au> References: <20050602094404.GA10316@gondor.apana.org.au> <20050602095459.GA26638@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2019 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 334 Lines: 10 From: Herbert Xu Date: Thu, 2 Jun 2005 19:54:59 +1000 > The call in question is only called from recvmsg which means that > IRQs aren't disabled. Therefore it is safe to replace it with > spin_lock_bh. > > Signed-off-by: Herbert Xu Also applied to net-2.6.13, thanks. From davem@davemloft.net Thu Jun 2 22:11:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 22:11:33 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j535BSXq007449 for ; Thu, 2 Jun 2005 22:11:29 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1De4Rv-0002Cn-3Z; Thu, 02 Jun 2005 22:10:27 -0700 Date: Thu, 02 Jun 2005 22:10:26 -0700 (PDT) Message-Id: <20050602.221026.112287995.davem@davemloft.net> To: herbert@gondor.apana.org.au Cc: netdev@oss.sgi.com Subject: Re: [IPV4/IPV6] Replace spin_lock_irq with spin_lock_bh From: "David S. Miller" In-Reply-To: <20050602094404.GA10316@gondor.apana.org.au> References: <20050602094404.GA10316@gondor.apana.org.au> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2018 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 570 Lines: 14 From: Herbert Xu Date: Thu, 2 Jun 2005 19:44:04 +1000 > In light of my recent patch to net/ipv4/udp.c that replaced the > spin_lock_irq calls on the receive queue lock with spin_lock_bh, > here is a similar patch for all other occurences of spin_lock_irq > on receive/error queue locks in IPv4 and IPv6. > > In these stacks, we know that they can only be entered from user > or softirq context. Therefore it's safe to disable BH only. > > Signed-off-by: Herbert Xu Applied to net-2.6.13, thanks Herbert. From davem@davemloft.net Thu Jun 2 22:09:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 22:10:00 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5359pXq007173 for ; Thu, 2 Jun 2005 22:09:52 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1De4QD-0002Bu-Br; Thu, 02 Jun 2005 22:08:41 -0700 Date: Thu, 02 Jun 2005 22:08:41 -0700 (PDT) Message-Id: <20050602.220841.48530513.davem@davemloft.net> To: hadi@cyberus.ca Cc: tgraf@suug.ch, netdev@oss.sgi.com Subject: Re: PATCH: explicit typing WAS(Re: PATCH: rtnetlink explicit flags setting From: "David S. Miller" In-Reply-To: <1117717493.6050.29.camel@localhost.localdomain> References: <20050531222646.GK15391@postel.suug.ch> <20050531.153125.95894437.davem@davemloft.net> <1117717493.6050.29.camel@localhost.localdomain> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2016 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 276 Lines: 9 From: jamal Date: Thu, 02 Jun 2005 09:04:52 -0400 > This patch converts "unsigned flags" to use more explict types like u16 > instead and incrementally introduces NLMSG_NEW(). > > Signed-off-by: Jamal Hadi Salim Applied, thanks Jamal. From kostodo@gmail.com Thu Jun 2 22:46:28 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 22:46:35 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j535kSXq011247 for ; Thu, 2 Jun 2005 22:46:28 -0700 Received: by rproxy.gmail.com with SMTP id z35so260962rne for ; Thu, 02 Jun 2005 22:45:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KQ5UPSnKzwwBGN3AFNeRIlX1sOp1cCO/MNatNpmKTAhYoLC1XeEAx3av3TlIqQZvlkMGDolXZe03jUYIGpqA2y7A+mmAtgXvqbB4ZKDzv8Mnnd86y8t+3XSeSlrwz8nxwsfXDtAkC3KJaI1bQsz25lDItg+8J98GonoMfPcqz1c= Received: by 10.38.88.3 with SMTP id l3mr730055rnb; Thu, 02 Jun 2005 22:45:30 -0700 (PDT) Received: by 10.38.208.46 with HTTP; Thu, 2 Jun 2005 22:45:30 -0700 (PDT) Message-ID: Date: Fri, 3 Jun 2005 09:45:30 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: Ben Greear Subject: Re: Network card driver problem (znb.o/tulip) Cc: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <428E0B3B.1090507@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428CC958.1080909@candelatech.com> <428E0B3B.1090507@candelatech.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j535kSXq011247 X-archive-position: 2020 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 5281 Lines: 152 I'm not too concerned with backward compatibility. I see silicom-usa provide both a Broadcom and Intel based chipsets. Is there any reason in particular that you reccomended Broadcom? And can standard kernel drivers be used for these cards? I've had bad expirience with custom manufactorer drivers once they discontinue development and support for their card. How reliable is Silicom-usa? As a management decision, who would you purchase 10 quad port cards from and which kinds of cards would u get? Thanks, K On 5/20/05, Ben Greear wrote: > Kosta Todorovic wrote: > > 2 more questions: > > > > 1) Is there anything special I will need to compile in terms of the > > linux kernel for 64-bit PCI bus mode (PCI-X) ? (Currently I'm using > > kernel 2.4.x but that is because my current card drivers do not > > support 2.6.x) > > Nothing special...2.4 and 2.6 kernels since way back will work just fine. > > > 2) The machine actually has a PCI extension with 9 other PCI-X slots. > > The current cards are 64-bit (pci-x) but as a test i'm planning on > > replacing them with DLinks DFE-580tx's. Unfortunately these are 32-bit > > cards (legacy pci). How will these 4 ports work in 32-bit mode? What > > will the effect be on the speed? > > If you put a 33Mhz NIC in a PCI-X bus it makes the entire bus run at > 33Mhz speed. > > If you do want full backwards compatibility, get the 'universal' 4-port > broadcom NIC from silicom-usa. It works fine in 32-bit PCI busses, and > though I haven't personally tested it, it should work fine in PCI-X > busses at high speed as well. > > Ben > > > > > > > > > On 5/19/05, Ben Greear wrote: > > > >>Kosta Todorovic wrote: > >> > >>>Whats the best 4-port NIC currently available? I'm interested in > >>>purchasing 10 4-port NICs as a replacement for my current cards. > >>> > >>>I am looking for 10/100Mbps and a good driver for linux (2.4.x and > >>>2.6.x). Preferably a mainstream company but thats not priority. > >>> > >>>Could the community please recommend the best card available? Money is > >>>not an issue since im really interested in the best of the best. > >> > >>Get an Intel 4-port GigE NIC. It will do 10/100/1000, and if you really > >>want to use all 4 ports at even 100Mbps, you need the 64-bit PCI bus... > >> > >>I have been getting mine from silicom-usa.com lately. They also have > >>6-port NICs, and 4-port broadcom GigE nics that can be used in 32-bit > >>PCI slots. (The Intel 4-port NICs will only work in 64-bit PCI slots.) > >> > >>If you really want 10/100 nics, try the p430tx from aei: > >>http://www.aei-it.com/hardware/fastenet/p430tx.htm > >> > >>These are like the old DFE570tx NICs, and use the tulip driver. They > >>are almost as expensive as the GigE NICs though... > >> > >>Thanks, > >>Ben > >> > >> > >>>Any suggestions? > >>> > >>>Regards, > >>>Kosta > >>> > >>> > >>> > >>>On 3/11/05, Kosta Todorovic wrote: > >>> > >>> > >>>>My company has recently purchased several ZNYX ZX274 network cards. > >>>>These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets. > >>>> > >>>>Unfortunately there exists no drivers for linux amd64 architecture. > >>>>There are 32bit drivers found at: > >>>>http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally > >>>>they wont compile under my amd64 system. > >>>> > >>>>The driver itself is called znb.o and can be downloaded from ZNYX's > >>>>website. I spoke to support staff there but they told me they have > >>>>discontinued support and development for this series of cards. > >>>> > >>>>The system I am running gentoo and have tried both 2.4.x and 2.6.x > >>>>kernels but no luck. > >>>> > >>>>Unfortunately there is NO 64bit drivers available for ANY platform. not even MS. > >>>> > >>>>Does anyone know of a customised znb.o driver built for amd64? > >>>>Is there any chance of anyone modifying the source code of the driver > >>>>to compile under a amd64 system? > >>>> > >>>>I've noticed that "tulip" drivers get loaded as a module at boot time. > >>>>but they dont function correctly. (lets you start the device and > >>>>attach ips but cant talk through it) > >>>> > >>>>Is there any variants of the tulip driver that will work for this? > >>>> > >>>>Help much appreciated. > >>>> > >>>> > >>>>/proc/pci extract for network cards: > >>>> > >>>> Bus 5, device 5, function 0: > >>>> Ethernet controller: Digital Equipment Corporation DECchip > >>>>21142/43 (#30) (rev 65). > >>>> IRQ 30. > >>>> Master Capable. Latency=128. Min Gnt=20.Max Lat=40. > >>>> I/O at 0x0 [0x7f]. > >>>> Non-prefetchable 32 bit memory at 0xfa1ff400 [0xfa1ff7ff]. > >>>> Bus 5, device 4, function 0: > >>>> Ethernet controller: Digital Equipment Corporation DECchip > >>>>21142/43 (#29) (rev 65). > >>>> IRQ 29. > >>>> Master Capable. No bursts. Min Gnt=20.Max Lat=40. > >>>> I/O at 0x0 [0x7f]. > >>>> Non-prefetchable 32 bit memory at 0xf9f00000 [0xf9f003ff]. > >>>> > >>> > >>> > >> > >>-- > >>Ben Greear > >>Candela Technologies Inc http://www.candelatech.com > >> > >> > > > > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From greearb@candelatech.com Thu Jun 2 22:54:57 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 22:55:00 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j535suXq012007 for ; Thu, 2 Jun 2005 22:54:56 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j536RJ5I026433; Thu, 2 Jun 2005 23:27:20 -0700 Message-ID: <429FF071.8040707@candelatech.com> Date: Thu, 02 Jun 2005 22:53:53 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kosta Todorovic CC: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: Network card driver problem (znb.o/tulip) References: <428CC958.1080909@candelatech.com> <428E0B3B.1090507@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2021 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1133 Lines: 30 Kosta Todorovic wrote: > I'm not too concerned with backward compatibility. I see silicom-usa > provide both a Broadcom and Intel based chipsets. > > Is there any reason in particular that you reccomended Broadcom? And > can standard kernel drivers be used for these cards? I've had bad > expirience with custom manufactorer drivers once they discontinue > development and support for their card. The BCM NICs will work in a normal 32-bit PCI bus..the 4-port Intels will not. If you have 64-bit PCI-X, then I'd get Intel..but that's just because I've used them longer...I have no reason to believe the BCM is inferior at this time. > How reliable is Silicom-usa? > > As a management decision, who would you purchase 10 quad port cards > from and which kinds of cards would u get? Heh, I've already purchased more than 10 from silicom, and have shipped them all over the world. So far...no complaints! But, if you don't need the BCM, you can get good ole Intel quad GigE NICs from www.newegg.com and a million other places. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From kostodo@gmail.com Thu Jun 2 23:00:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 23:00:39 -0700 (PDT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5360aXq014080 for ; Thu, 2 Jun 2005 23:00:36 -0700 Received: by rproxy.gmail.com with SMTP id z35so262012rne for ; Thu, 02 Jun 2005 22:59:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MqhClYLMKtWNDtSO9HOZE3iKsNC79hPqIupJwBH2jx6xreuo5TRlp9QQFHhzyGLH5SLAhrmumGFo4fiZ1vFXdn/aagDSzJDm86MD91MT/9f8Xb6GAGMIa+w9ejQB8Rhwa4zQcP1uiiE7mPh7ik91ChBO2Huj4Cq1uNzTH4RBzvI= Received: by 10.38.88.1 with SMTP id l1mr727356rnb; Thu, 02 Jun 2005 22:58:44 -0700 (PDT) Received: by 10.38.208.46 with HTTP; Thu, 2 Jun 2005 22:58:44 -0700 (PDT) Message-ID: Date: Fri, 3 Jun 2005 09:58:44 +0400 From: Kosta Todorovic Reply-To: Kosta Todorovic To: Ben Greear Subject: Re: Network card driver problem (znb.o/tulip) Cc: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <429FF071.8040707@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <428CC958.1080909@candelatech.com> <428E0B3B.1090507@candelatech.com> <429FF071.8040707@candelatech.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j5360aXq014080 X-archive-position: 2022 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kostodo@gmail.com Precedence: bulk X-list: netdev Content-Length: 1341 Lines: 36 So intel gigE nics use standard tulip linux drivers that come shipped with a vanilla kernel? On 6/3/05, Ben Greear wrote: > Kosta Todorovic wrote: > > I'm not too concerned with backward compatibility. I see silicom-usa > > provide both a Broadcom and Intel based chipsets. > > > > Is there any reason in particular that you reccomended Broadcom? And > > can standard kernel drivers be used for these cards? I've had bad > > expirience with custom manufactorer drivers once they discontinue > > development and support for their card. > > The BCM NICs will work in a normal 32-bit PCI bus..the 4-port Intels will > not. If you have 64-bit PCI-X, then I'd get Intel..but that's just because > I've used them longer...I have no reason to believe the BCM is inferior at > this time. > > > How reliable is Silicom-usa? > > > > As a management decision, who would you purchase 10 quad port cards > > from and which kinds of cards would u get? > > Heh, I've already purchased more than 10 from silicom, and have shipped > them all over the world. So far...no complaints! But, if you don't > need the BCM, you can get good ole Intel quad GigE NICs from www.newegg.com > and a million other places. > > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > From greearb@candelatech.com Thu Jun 2 23:26:56 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 02 Jun 2005 23:27:00 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j536QuXq015870 for ; Thu, 2 Jun 2005 23:26:56 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j536xJ5I026786; Thu, 2 Jun 2005 23:59:19 -0700 Message-ID: <429FF7F0.7050505@candelatech.com> Date: Thu, 02 Jun 2005 23:25:52 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kosta Todorovic CC: jgarzik@pobox.com, tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: Network card driver problem (znb.o/tulip) References: <428CC958.1080909@candelatech.com> <428E0B3B.1090507@candelatech.com> <429FF071.8040707@candelatech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2023 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 369 Lines: 15 Kosta Todorovic wrote: > So intel gigE nics use standard tulip linux drivers that come shipped > with a vanilla kernel? No..forget about tulip. It uses standard e1000 driver shipped with vanilla kernel. The BCM chipsets use standard drivers in the kernel as well. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jbenc@suse.cz Fri Jun 3 02:34:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 02:34:46 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j539YgXq029261 for ; Fri, 3 Jun 2005 02:34:43 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 1EC99628312; Fri, 3 Jun 2005 11:33:44 +0200 (CEST) Date: Fri, 3 Jun 2005 11:33:43 +0200 From: Jiri Benc To: Cc: , Subject: Re: [PATCH] ieee80211: Update generic definitions to latest specs. Message-ID: <20050603113343.55d19cfc@griffin.suse.cz> In-Reply-To: <20050602190232.340996282D7@mail.suse.cz> References: <20050602190232.340996282D7@mail.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2024 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 753 Lines: 24 On Thu, 2 Jun 2005 21:02:24 +0200, gwingerde@home.nl wrote: > I was thinking about that too, but couldn't find a proper shorter > version without losing the descriptive meaning. > > Do you have any suggestions to shorten them? Maybe we can lose a bit of descriptiveness and put comments above definitions instead? I can imagine names such as WLAN_STATUS_ASSOC_DENIED_NOSPECTRUM, WLAN_STATUS_ASSOC_DENIED_BAD_POWER, WLAN_STATUS_ASSOC_DENIED_BAD_SUPPCHANNS, WLAN_REASON_DISASSOC_BAD_POWER, and so on. Also WLAN_STATUS_ASSOC_DENIED_NOSHORT seems to be acceptable for me. More often used identifiers probably could have even shorter name - what about renaming IEEE80211_FCTL_PROTECTEDFRAME to IEEE80211_FCTL_PROTECTED? Thanks, -- Jiri Benc SUSE Labs From baruch@ev-en.org Fri Jun 3 06:43:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 06:44:06 -0700 (PDT) Received: from galon.ev-en.org (rrcs-24-123-59-149.central.biz.rr.com [24.123.59.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53DhvXq018401 for ; Fri, 3 Jun 2005 06:43:58 -0700 Received: by galon.ev-en.org (Postfix, from userid 105) id 3DBED11A953; Fri, 3 Jun 2005 16:42:59 +0300 (IDT) Received: from [10.220.3.66] (hamilton.nuim.ie [149.157.192.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by galon.ev-en.org (Postfix) with ESMTP id 5196D11A951; Fri, 3 Jun 2005 16:42:53 +0300 (IDT) Message-ID: <42A05E5C.9050408@ev-en.org> Date: Fri, 03 Jun 2005 14:42:52 +0100 From: Baruch Even User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com, shemminger@osdl.org, doug.leith@nuim.ie Subject: Re: Comparison of several congestion control algorithms References: <4298E045.9050009@ev-en.org> <20050602.163512.10298458.davem@davemloft.net> <429F9B2F.8030507@ev-en.org> <20050602.165341.63126720.davem@davemloft.net> In-Reply-To: <20050602.165341.63126720.davem@davemloft.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 2025 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: baruch@ev-en.org Precedence: bulk X-list: netdev Content-Length: 936 Lines: 27 David S. Miller wrote: > From: Baruch Even > Date: Fri, 03 Jun 2005 00:50:07 +0100 > > >>This is in part because of the start of the work that was based on 2.4 >>kernels and even as far as the 2.6.6 kernel which had disabled TSO once >>it saw SACKs. This made TSO unusable for our needs. >> >>AFAIK, the tests reported in that document used kernel 2.6.6. > > > Sure SACKs turn off TSO currently, but you'll have them enabled > at the beginning until the first loss and this affects how fast > the cwnd will grow. > > If you have e1000 cards, for example, you're getting TSO enabled > by default. > > You really need to look into this, as it has a real and very > non-trivial effect on all of the results you obtained. I checked that now and ethtool -k shows TSO to be disabled after boot. Since all the test scripts are not playing with ethtool I can be sure that TSO was off during all of our tests. Baruch From jbenc@suse.cz Fri Jun 3 09:27:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:27:31 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GROXq031421 for ; Fri, 3 Jun 2005 09:27:24 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 8B6CE6282FC; Fri, 3 Jun 2005 18:26:25 +0200 (CEST) Date: Fri, 3 Jun 2005 18:26:25 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [0/9] ieee80211: Improvements to the layer Message-ID: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2026 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 456 Lines: 14 Following patches are nearly the same as were sent couple of days ago. However, they are against current netdev-2.6 tree and they contain some more fixes (TKIP compilation, new file for protocol layer functions). The HH_DATA_OFF bugfix is needed too (http://oss.sgi.com/projects/netdev/archive/2005-05/msg00962.html), it's not included here as it is in Linus' tree already. Also there are two patches from Adrian Bunk included. -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:29:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:29:23 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GTIXq031749 for ; Fri, 3 Jun 2005 09:29:18 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id EBDDB628305; Fri, 3 Jun 2005 18:28:19 +0200 (CEST) Date: Fri, 3 Jun 2005 18:28:19 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [1/9] ieee80211: remove pci.h #include's Message-ID: <20050603182819.44500c27@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2027 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 1527 Lines: 44 From: Adrian Bunk I was wondering why editing pci.h triggered the rebuild of three files under net/, and as far as I can see, there's no reason for these three files to #include pci.h . Signed-off-by: Adrian Bunk Signed-off-by: Jiri Benc --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c.old 2005-04-30 23:23:14.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c 2005-04-30 23:23:18.000000000 +0200 @@ -40,7 +40,6 @@ #include #include #include -#include #include #include #include --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c.old 2005-04-30 23:23:25.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c 2005-04-30 23:23:32.000000000 +0200 @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include --- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c.old 2005-04-30 23:23:42.000000000 +0200 +++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c 2005-04-30 23:23:46.000000000 +0200 @@ -23,7 +23,6 @@ #include #include #include -#include #include #include #include -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:30:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:30:22 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GUIXq032183 for ; Fri, 3 Jun 2005 09:30:18 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 5C4466282FC; Fri, 3 Jun 2005 18:29:20 +0200 (CEST) Date: Fri, 3 Jun 2005 18:29:20 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [2/9] ieee80211: fix recursive ipw2200 dependencies Message-ID: <20050603182920.689a269f@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2028 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 896 Lines: 32 From: Adrian Bunk This results in recursive dependencies: - IPW2200 depends on NET_RADIO - IPW2200 selects IEEE80211 - IEEE80211 selects NET_RADIO This patch fixes the IPW2200 dependencies in a way that they are similar to the IPW2100 dependencies. Signed-off-by: Adrian Bunk Signed-off-by: Jiri Benc --- linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig.old 2005-06-02 22:04:02.000000000 +0200 +++ linux-2.6.12-rc5-mm2-full/drivers/net/wireless/Kconfig 2005-06-02 22:04:40.000000000 +0200 @@ -192,9 +192,8 @@ config IPW2200 tristate "Intel PRO/Wireless 2200BG and 2915ABG Network Connection" - depends on NET_RADIO && PCI + depends on IEEE80211 && PCI select FW_LOADER - select IEEE80211 ---help--- A driver for the Intel PRO/Wireless 2200BG and 2915ABG Network Connection adapters. -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:31:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:31:51 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GVkXq000509 for ; Fri, 3 Jun 2005 09:31:47 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 5E157628305; Fri, 3 Jun 2005 18:30:48 +0200 (CEST) Date: Fri, 3 Jun 2005 18:30:48 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [3/9] ieee80211: fix ipw 64bit compilation warnings Message-ID: <20050603183048.7786f98b@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2029 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 7028 Lines: 237 This patch fixes warnings when compiling ipw2100 and ipw2200 on x86_64. Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac Index: netdev/drivers/net/wireless/ipw2200.c =================================================================== --- netdev.orig/drivers/net/wireless/ipw2200.c 2005-06-01 11:03:37.000000000 +0200 +++ netdev/drivers/net/wireless/ipw2200.c 2005-06-03 15:46:31.000000000 +0200 @@ -241,8 +241,8 @@ IPW_DEBUG_IO(" reg = 0x%8X : value = 0x%8X\n", reg, value); _ipw_write32(priv, CX2_INDIRECT_ADDR, reg & CX2_INDIRECT_ADDR_MASK); _ipw_write8(priv, CX2_INDIRECT_DATA, value); - IPW_DEBUG_IO(" reg = 0x%8X : value = 0x%8X\n", - (unsigned)(priv->hw_base + CX2_INDIRECT_DATA), + IPW_DEBUG_IO(" reg = 0x%8lX : value = 0x%8X\n", + (unsigned long)(priv->hw_base + CX2_INDIRECT_DATA), value); } @@ -508,7 +508,7 @@ /* verify we have enough room to store the value */ if (*len < sizeof(u32)) { IPW_DEBUG_ORD("ordinal buffer length too small, " - "need %d\n", sizeof(u32)); + "need %d\n", (int)sizeof(u32)); return -EINVAL; } @@ -541,7 +541,7 @@ /* verify we have enough room to store the value */ if (*len < sizeof(u32)) { IPW_DEBUG_ORD("ordinal buffer length too small, " - "need %d\n", sizeof(u32)); + "need %d\n", (int)sizeof(u32)); return -EINVAL; } @@ -1740,7 +1740,7 @@ u32 address = CX2_SHARED_SRAM_DMA_CONTROL + (sizeof(struct command_block) * index); IPW_DEBUG_FW(">> :\n"); - ipw_write_indirect(priv, address, (u8*)cb, sizeof(struct command_block)); + ipw_write_indirect(priv, address, (u8*)cb, (int)sizeof(struct command_block)); IPW_DEBUG_FW("<< :\n"); return 0; @@ -2342,11 +2342,11 @@ return -EINVAL; } - IPW_DEBUG_INFO("Loading firmware '%s' file v%d.%d (%d bytes)\n", + IPW_DEBUG_INFO("Loading firmware '%s' file v%d.%d (%ld bytes)\n", name, IPW_FW_MAJOR(header->version), IPW_FW_MINOR(header->version), - (*fw)->size - sizeof(struct fw_header)); + (long)(*fw)->size - sizeof(struct fw_header)); return 0; } @@ -2698,7 +2698,7 @@ q->bd = pci_alloc_consistent(dev,sizeof(q->bd[0])*count, &q->q.dma_addr); if (!q->bd) { IPW_ERROR("pci_alloc_consistent(%d) failed\n", - sizeof(q->bd[0]) * count); + (int)sizeof(q->bd[0]) * count); kfree(q->txb); q->txb = NULL; return -ENOMEM; @@ -3467,7 +3467,7 @@ } else { IPW_DEBUG_SCAN("Scan result of wrong size %d " "(should be %d)\n", - notif->size,sizeof(*x)); + notif->size, (int)sizeof(*x)); } break; } @@ -3483,7 +3483,7 @@ } else { IPW_ERROR("Scan completed of wrong size %d " "(should be %d)\n", - notif->size,sizeof(*x)); + notif->size, (int)sizeof(*x)); } priv->status &= ~(STATUS_SCANNING | STATUS_SCAN_ABORTING); @@ -3516,7 +3516,7 @@ } else { IPW_ERROR("Frag length of wrong size %d " "(should be %d)\n", - notif->size, sizeof(*x)); + notif->size, (int)sizeof(*x)); } break; } @@ -3533,7 +3533,7 @@ } else { IPW_ERROR("Link Deterioration of wrong size %d " "(should be %d)\n", - notif->size,sizeof(*x)); + notif->size, (int)sizeof(*x)); } break; } @@ -3552,7 +3552,7 @@ struct notif_beacon_state *x = ¬if->u.beacon_state; if (notif->size != sizeof(*x)) { IPW_ERROR("Beacon state of wrong size %d (should " - "be %d)\n", notif->size, sizeof(*x)); + "be %d)\n", notif->size, (int)sizeof(*x)); break; } @@ -3603,7 +3603,7 @@ } IPW_ERROR("TGi Tx Key of wrong size %d (should be %d)\n", - notif->size,sizeof(*x)); + notif->size, (int)sizeof(*x)); break; } @@ -3617,7 +3617,7 @@ } IPW_ERROR("Calibration of wrong size %d (should be %d)\n", - notif->size,sizeof(*x)); + notif->size, (int)sizeof(*x)); break; } @@ -3629,7 +3629,7 @@ } IPW_ERROR("Noise stat is wrong size %d (should be %d)\n", - notif->size, sizeof(u32)); + notif->size, (int)sizeof(u32)); break; } @@ -4823,7 +4823,7 @@ } /* Advance skb->data to the start of the actual payload */ - skb_reserve(rxb->skb, (u32)&pkt->u.frame.data[0] - (u32)pkt); + skb_reserve(rxb->skb, offsetof(struct ipw_rx_packet, u.frame.data)); /* Set the size of the skb to the size of the frame */ skb_put(rxb->skb, pkt->u.frame.length); Index: netdev/drivers/net/wireless/ipw2100.c =================================================================== --- netdev.orig/drivers/net/wireless/ipw2100.c 2005-06-01 11:03:37.000000000 +0200 +++ netdev/drivers/net/wireless/ipw2100.c 2005-06-03 15:43:53.000000000 +0200 @@ -494,7 +494,7 @@ IPW_DEBUG_WARNING(DRV_NAME ": ordinal buffer length too small, need %d\n", - IPW_ORD_TAB_1_ENTRY_SIZE); + (int)IPW_ORD_TAB_1_ENTRY_SIZE); return -EINVAL; } @@ -2302,7 +2302,7 @@ #endif IPW_DEBUG_INFO(DRV_NAME ": PCI latency error detected at " - "0x%04X.\n", i * sizeof(struct ipw2100_status)); + "0x%04X.\n", i * (int)sizeof(struct ipw2100_status)); #ifdef ACPI_CSTATE_LIMIT_DEFINED IPW_DEBUG_INFO(DRV_NAME ": Disabling C3 transitions.\n"); @@ -2398,7 +2398,7 @@ /* Make a copy of the frame so we can dump it to the logs if * ieee80211_rx fails */ memcpy(packet_data, packet->skb->data, - min(status->frame_size, IPW_RX_NIC_BUFFER_LENGTH)); + min_t(u32, status->frame_size, IPW_RX_NIC_BUFFER_LENGTH)); #endif if (!ieee80211_rx(priv->ieee, packet->skb, stats)) { @@ -2730,21 +2730,21 @@ { int i = txq->oldest; IPW_DEBUG_TX( - "TX%d V=%p P=%p T=%p L=%d\n", i, + "TX%d V=%p P=%04X T=%04X L=%d\n", i, &txq->drv[i], - (void*)txq->nic + i * sizeof(struct ipw2100_bd), - (void*)txq->drv[i].host_addr, + (u32)(txq->nic + i * sizeof(struct ipw2100_bd)), + txq->drv[i].host_addr, txq->drv[i].buf_length); if (packet->type == DATA) { i = (i + 1) % txq->entries; IPW_DEBUG_TX( - "TX%d V=%p P=%p T=%p L=%d\n", i, + "TX%d V=%p P=%04X T=%04X L=%d\n", i, &txq->drv[i], - (void*)txq->nic + i * - sizeof(struct ipw2100_bd), - (void*)txq->drv[i].host_addr, + (u32)(txq->nic + i * + sizeof(struct ipw2100_bd)), + (u32)txq->drv[i].host_addr, txq->drv[i].buf_length); } } @@ -4212,7 +4212,7 @@ { IPW_DEBUG_INFO("enter\n"); - IPW_DEBUG_INFO("initializing bd queue at virt=%p, phys=%08x\n", q->drv, q->nic); + IPW_DEBUG_INFO("initializing bd queue at virt=%p, phys=%08x\n", q->drv, (u32)q->nic); write_register(priv->net_dev, base, q->nic); write_register(priv->net_dev, size, q->entries); @@ -8431,8 +8431,8 @@ priv->net_dev->name, fw_name); return rc; } - IPW_DEBUG_INFO("firmware data %p size %d\n", fw->fw_entry->data, - fw->fw_entry->size); + IPW_DEBUG_INFO("firmware data %p size %ld\n", fw->fw_entry->data, + (long)fw->fw_entry->size); ipw2100_mod_firmware_load(fw); -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:32:48 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:32:51 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GWlXq000977 for ; Fri, 3 Jun 2005 09:32:48 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 6E2FD6282FC; Fri, 3 Jun 2005 18:31:49 +0200 (CEST) Date: Fri, 3 Jun 2005 18:31:49 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [4/9] ieee80211: ieee80211_device alignment fix and cleanup Message-ID: <20050603183149.228ab747@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2030 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 9617 Lines: 310 Changes to the ieee80211 layer: - fixes a serious alignment problem of the driver's private data - makes the drivers use the ieee80211_device instead of the net_device where appropriate (will ease further development of ieee80211 as a self-contained layer) Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac Index: netdev/include/net/ieee80211.h =================================================================== --- netdev.orig/include/net/ieee80211.h 2005-06-01 11:05:06.000000000 +0200 +++ netdev/include/net/ieee80211.h 2005-06-03 13:20:46.000000000 +0200 @@ -704,15 +704,13 @@ int abg_ture; /* ABG flag */ /* Callback functions */ - void (*set_security)(struct net_device *dev, + void (*set_security)(struct ieee80211_device *ieee, struct ieee80211_security *sec); int (*hard_start_xmit)(struct ieee80211_txb *txb, - struct net_device *dev); - int (*reset_port)(struct net_device *dev); + struct ieee80211_device *ieee); + int (*reset_port)(struct ieee80211_device *ieee); - /* This must be the last item so that it points to the data - * allocated beyond this structure by alloc_ieee80211 */ - u8 priv[0]; + void *priv; }; #define IEEE_A (1<<0) @@ -720,9 +718,27 @@ #define IEEE_G (1<<2) #define IEEE_MODE_MASK (IEEE_A|IEEE_B|IEEE_G) -extern inline void *ieee80211_priv(struct net_device *dev) +static inline void *ieee80211_priv(struct ieee80211_device *ieee) { - return ((struct ieee80211_device *)netdev_priv(dev))->priv; + return (char *)ieee + + ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST); +} + +static inline void *ieee80211_dev_to_priv(struct net_device *dev) +{ + return (char *)dev + + ((sizeof(struct net_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST) + + ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST); +} + +static inline struct net_device *ieee80211_dev(struct ieee80211_device *ieee) +{ + return (struct net_device *)((char *)ieee - + ((sizeof(struct net_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST)); } extern inline int ieee80211_is_empty_essid(const char *essid, int essid_len) @@ -795,8 +811,8 @@ /* ieee80211.c */ -extern void free_ieee80211(struct net_device *dev); -extern struct net_device *alloc_ieee80211(int sizeof_priv); +extern void free_ieee80211(struct ieee80211_device *ieee); +extern struct ieee80211_device *alloc_ieee80211(int sizeof_priv); extern int ieee80211_set_encryption(struct ieee80211_device *ieee); Index: netdev/net/ieee80211/ieee80211_module.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_module.c 2005-06-03 13:20:40.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_module.c 2005-06-03 13:20:46.000000000 +0200 @@ -69,7 +69,7 @@ GFP_KERNEL); if (!ieee->networks) { printk(KERN_WARNING "%s: Out of memory allocating beacons\n", - ieee->dev->name); + ieee80211_dev(ieee)->name); return -ENOMEM; } @@ -98,23 +98,28 @@ } -struct net_device *alloc_ieee80211(int sizeof_priv) +struct ieee80211_device *alloc_ieee80211(int sizeof_priv) { struct ieee80211_device *ieee; struct net_device *dev; + int alloc_size; int err; IEEE80211_DEBUG_INFO("Initializing...\n"); - dev = alloc_etherdev(sizeof(struct ieee80211_device) + sizeof_priv); + alloc_size = ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST) + + sizeof_priv; + dev = alloc_etherdev(alloc_size); if (!dev) { IEEE80211_ERROR("Unable to network device.\n"); goto failed; } ieee = netdev_priv(dev); - dev->hard_start_xmit = ieee80211_xmit; - ieee->dev = dev; + ieee->priv = ieee80211_priv(ieee); + + dev->hard_start_xmit = ieee80211_xmit; err = ieee80211_networks_allocate(ieee); if (err) { @@ -147,7 +152,7 @@ ieee->privacy_invoked = 0; ieee->ieee802_1x = 1; - return dev; + return ieee; failed: if (dev) @@ -156,10 +161,8 @@ } -void free_ieee80211(struct net_device *dev) +void free_ieee80211(struct ieee80211_device *ieee) { - struct ieee80211_device *ieee = netdev_priv(dev); - int i; del_timer_sync(&ieee->crypt_deinit_timer); @@ -178,7 +181,7 @@ } ieee80211_networks_free(ieee); - free_netdev(dev); + free_netdev(ieee80211_dev(ieee)); } #ifdef CONFIG_IEEE80211_DEBUG Index: netdev/net/ieee80211/ieee80211_rx.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_rx.c 2005-06-03 13:20:40.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_rx.c 2005-06-03 13:20:46.000000000 +0200 @@ -99,7 +99,7 @@ if (frag == 0) { /* Reserve enough space to fit maximum frame length */ - skb = dev_alloc_skb(ieee->dev->mtu + + skb = dev_alloc_skb(ieee80211_dev(ieee)->mtu + sizeof(struct ieee80211_hdr) + 8 /* LLC */ + 2 /* alignment */ + @@ -175,7 +175,7 @@ { if (ieee->iw_mode == IW_MODE_MASTER) { printk(KERN_DEBUG "%s: Master mode not yet suppported.\n", - ieee->dev->name); + ieee80211_dev(ieee)->name); return 0; /* hostap_update_sta_ps(ieee, (struct hostap_ieee80211_hdr *) @@ -233,7 +233,7 @@ static int ieee80211_is_eapol_frame(struct ieee80211_device *ieee, struct sk_buff *skb) { - struct net_device *dev = ieee->dev; + struct net_device *dev = ieee80211_dev(ieee); u16 fc, ethertype; struct ieee80211_hdr *hdr; u8 *pos; @@ -289,7 +289,7 @@ if (net_ratelimit()) { printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " "received packet from " MAC_FMT "\n", - ieee->dev->name, MAC_ARG(hdr->addr2)); + ieee80211_dev(ieee)->name, MAC_ARG(hdr->addr2)); } return -1; } @@ -334,7 +334,7 @@ if (res < 0) { printk(KERN_DEBUG "%s: MSDU decryption/MIC verification failed" " (SA=" MAC_FMT " keyidx=%d)\n", - ieee->dev->name, MAC_ARG(hdr->addr2), keyidx); + ieee80211_dev(ieee)->name, MAC_ARG(hdr->addr2), keyidx); return -1; } @@ -348,7 +348,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct sk_buff *skb, struct ieee80211_rx_stats *rx_stats) { - struct net_device *dev = ieee->dev; + struct net_device *dev = ieee80211_dev(ieee); struct ieee80211_hdr *hdr; size_t hdrlen; u16 fc, type, stype, sc; @@ -1194,7 +1194,7 @@ IEEE80211_DEBUG_MGMT("received UNKNOWN (%d)\n", WLAN_FC_GET_STYPE(header->frame_ctl)); IEEE80211_WARNING("%s: Unknown management packet: %d\n", - ieee->dev->name, + ieee80211_dev(ieee)->name, WLAN_FC_GET_STYPE(header->frame_ctl)); break; } Index: netdev/net/ieee80211/ieee80211_tx.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_tx.c 2005-06-03 13:20:40.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_tx.c 2005-06-03 13:20:46.000000000 +0200 @@ -171,7 +171,7 @@ if (net_ratelimit()) { printk(KERN_DEBUG "%s: TKIP countermeasures: dropped " "TX packet to " MAC_FMT "\n", - ieee->dev->name, MAC_ARG(header->addr1)); + ieee80211_dev(ieee)->name, MAC_ARG(header->addr1)); } return -1; } @@ -192,7 +192,7 @@ atomic_dec(&crypt->refcnt); if (res < 0) { printk(KERN_INFO "%s: Encryption failed: len=%d.\n", - ieee->dev->name, frag->len); + ieee80211_dev(ieee)->name, frag->len); ieee->ieee_stats.tx_discards++; return -1; } @@ -269,13 +269,13 @@ * creating it... */ if (!ieee->hard_start_xmit) { printk(KERN_WARNING "%s: No xmit handler.\n", - ieee->dev->name); + dev->name); goto success; } if (unlikely(skb->len < SNAP_SIZE + sizeof(u16))) { printk(KERN_WARNING "%s: skb too small (%d).\n", - ieee->dev->name, skb->len); + dev->name, skb->len); goto success; } @@ -371,7 +371,7 @@ txb = ieee80211_alloc_txb(nr_frags, frag_size, GFP_ATOMIC); if (unlikely(!txb)) { printk(KERN_WARNING "%s: Could not allocate TXB\n", - ieee->dev->name); + dev->name); goto failed; } txb->encrypted = encrypt; @@ -426,7 +426,7 @@ dev_kfree_skb_any(skb); if (txb) { - if ((*ieee->hard_start_xmit)(txb, dev) == 0) { + if ((*ieee->hard_start_xmit)(txb, ieee) == 0) { stats->tx_packets++; stats->tx_bytes += txb->payload_size; return 0; Index: netdev/net/ieee80211/ieee80211_wx.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_wx.c 2005-06-01 11:05:14.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_wx.c 2005-06-03 13:20:46.000000000 +0200 @@ -252,7 +252,7 @@ union iwreq_data *wrqu, char *keybuf) { struct iw_point *erq = &(wrqu->encoding); - struct net_device *dev = ieee->dev; + struct net_device *dev = ieee80211_dev(ieee); struct ieee80211_security sec = { .flags = 0 }; @@ -402,7 +402,7 @@ sec.level = SEC_LEVEL_1; /* 40 and 104 bit WEP */ if (ieee->set_security) - ieee->set_security(dev, &sec); + ieee->set_security(ieee, &sec); /* Do not reset port if card is in Managed mode since resetting will * generate new IEEE 802.11 authentication which may end up in looping @@ -411,7 +411,7 @@ * the callbacks structures used to initialize the 802.11 stack. */ if (ieee->reset_on_keychange && ieee->iw_mode != IW_MODE_INFRA && - ieee->reset_port && ieee->reset_port(dev)) { + ieee->reset_port && ieee->reset_port(ieee)) { printk(KERN_DEBUG "%s: reset_port failed\n", dev->name); return -EINVAL; } -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:33:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:33:57 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GXqXq001489 for ; Fri, 3 Jun 2005 09:33:53 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 86D3B6282FC; Fri, 3 Jun 2005 18:32:54 +0200 (CEST) Date: Fri, 3 Jun 2005 18:32:54 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [5/9] ipw: fix after "ieee80211_device alignment fix" Message-ID: <20050603183254.03afaa81@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2031 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 30535 Lines: 1000 Fixes ipw2100 and ipw2200 after the API change (alignment, struct iee80211_device). Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac Index: netdev/drivers/net/wireless/ipw2100.c =================================================================== --- netdev.orig/drivers/net/wireless/ipw2100.c 2005-06-01 11:03:37.000000000 +0200 +++ netdev/drivers/net/wireless/ipw2100.c 2005-06-03 11:57:33.000000000 +0200 @@ -1772,7 +1772,7 @@ /* Called by register_netdev() */ static int ipw2100_net_init(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); return ipw2100_up(priv, 1); } @@ -3248,9 +3248,9 @@ return IRQ_NONE; } -static int ipw2100_tx(struct ieee80211_txb *txb, struct net_device *dev) +static int ipw2100_tx(struct ieee80211_txb *txb, struct ieee80211_device *ieee) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(ieee); struct list_head *element; struct ipw2100_tx_packet *packet; unsigned long flags; @@ -3260,7 +3260,7 @@ if (!(priv->status & STATUS_ASSOCIATED)) { IPW_DEBUG_INFO("Can not transmit when not connected.\n"); priv->ieee->stats.tx_carrier_errors++; - netif_stop_queue(dev); + netif_stop_queue(ieee80211_dev(ieee)); goto fail_unlock; } @@ -3291,7 +3291,7 @@ return 0; fail_unlock: - netif_stop_queue(dev); + netif_stop_queue(ieee80211_dev(ieee)); spin_unlock_irqrestore(&priv->low_lock, flags); return 1; } @@ -5418,10 +5418,10 @@ ipw2100_configure_security(priv, 0); } -static void shim__set_security(struct net_device *dev, +static void shim__set_security(struct ieee80211_device *ieee, struct ieee80211_security *sec) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(ieee); int i, force_update = 0; down(&priv->action_sem); @@ -5609,7 +5609,7 @@ * method as well) to talk to the firmware */ static int ipw2100_set_address(struct net_device *dev, void *p) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); struct sockaddr *addr = p; int err = 0; @@ -5637,7 +5637,7 @@ static int ipw2100_open(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); unsigned long flags; IPW_DEBUG_INFO("dev->open\n"); @@ -5651,7 +5651,7 @@ static int ipw2100_close(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); unsigned long flags; struct list_head *element; struct ipw2100_tx_packet *packet; @@ -5692,7 +5692,7 @@ */ static void ipw2100_tx_timeout(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); priv->ieee->stats.tx_errors++; @@ -5715,7 +5715,7 @@ */ static struct net_device_stats *ipw2100_stats(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); return &priv->ieee->stats; } @@ -5802,7 +5802,7 @@ } if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); else ret = -EOPNOTSUPP; @@ -5829,7 +5829,7 @@ } if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); else ret = -EOPNOTSUPP; @@ -5839,7 +5839,7 @@ static int ipw2100_wpa_set_param(struct net_device *dev, u8 name, u32 value){ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int ret=0; switch(name){ @@ -5878,7 +5878,7 @@ static int ipw2100_wpa_mlme(struct net_device *dev, int command, int reason){ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int ret=0; switch(command){ @@ -5920,8 +5920,8 @@ static int ipw2100_wpa_set_wpa_ie(struct net_device *dev, struct ipw2100_param *param, int plen){ - struct ipw2100_priv *priv = ieee80211_priv(dev); - struct ieee80211_device *ieee = priv->ieee; + struct ieee80211_device *ieee = netdev_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(ieee); u8 *buf; if (! ieee->wpa_enabled) @@ -5960,8 +5960,8 @@ struct ipw2100_param *param, int param_len){ int ret = 0; - struct ipw2100_priv *priv = ieee80211_priv(dev); - struct ieee80211_device *ieee = priv->ieee; + struct ieee80211_device *ieee = netdev_priv(dev); + struct ipw2100_priv *priv = ieee80211_priv(ieee); struct ieee80211_crypto_ops *ops; struct ieee80211_crypt_data **crypt; @@ -6081,7 +6081,7 @@ } done: if (ieee->set_security) - ieee->set_security(ieee->dev, &sec); + ieee->set_security(ieee, &sec); /* Do not reset port if card is in Managed mode since resetting will * generate new IEEE 802.11 authentication which may end up in looping @@ -6178,7 +6178,7 @@ static void ipw_ethtool_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); char fw_ver[64], ucode_ver[64]; strcpy(info->driver, DRV_NAME); @@ -6195,7 +6195,7 @@ static u32 ipw2100_ethtool_get_link(struct net_device *dev) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); return (priv->status & STATUS_ASSOCIATED) ? 1 : 0; } @@ -6288,12 +6288,14 @@ { struct ipw2100_priv *priv; struct net_device *dev; + struct ieee80211_device *ieee; - dev = alloc_ieee80211(sizeof(struct ipw2100_priv)); - if (!dev) + ieee = alloc_ieee80211(sizeof(struct ipw2100_priv)); + if (!ieee) return NULL; - priv = ieee80211_priv(dev); - priv->ieee = netdev_priv(dev); + dev = ieee80211_dev(ieee); + priv = ieee80211_priv(ieee); + priv->ieee = ieee; priv->pci_dev = pci_dev; priv->net_dev = dev; @@ -6477,7 +6479,7 @@ return err; } - priv = ieee80211_priv(dev); + priv = ieee80211_dev_to_priv(dev); pci_set_master(pci_dev); pci_set_drvdata(pci_dev, priv); @@ -6618,7 +6620,7 @@ ipw2100_queues_free(priv); sysfs_remove_group(&pci_dev->dev.kobj, &ipw2100_attribute_group); - free_ieee80211(dev); + free_ieee80211(netdev_priv(dev)); pci_set_drvdata(pci_dev, NULL); } @@ -6675,7 +6677,7 @@ if (dev->base_addr) iounmap((unsigned char *)dev->base_addr); - free_ieee80211(dev); + free_ieee80211(netdev_priv(dev)); } pci_release_regions(pci_dev); @@ -6918,7 +6920,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); if (!(priv->status & STATUS_ASSOCIATED)) strcpy(wrqu->name, "unassociated"); else @@ -6933,7 +6935,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); struct iw_freq *fwrq = &wrqu->freq; int err = 0; @@ -6984,7 +6986,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); wrqu->freq.e = 0; @@ -7005,7 +7007,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int err = 0; IPW_DEBUG_WX("SET Mode -> %d \n", wrqu->mode); @@ -7048,7 +7050,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); wrqu->mode = priv->ieee->iw_mode; IPW_DEBUG_WX("GET Mode -> %d\n", wrqu->mode); @@ -7084,7 +7086,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); struct iw_range *range = (struct iw_range *)extra; u16 val; int i, level; @@ -7196,7 +7198,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int err = 0; static const unsigned char any[] = { @@ -7251,7 +7253,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); /* If we are associated, trying to associate, or have a statically * configured BSSID then return that; otherwise return ANY */ @@ -7271,7 +7273,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); char *essid = ""; /* ANY */ int length = 0; int err = 0; @@ -7325,7 +7327,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); /* If we are associated, trying to associate, or have a statically * configured ESSID then return that; otherwise return ANY */ @@ -7353,7 +7355,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); if (wrqu->data.length > IW_ESSID_MAX_SIZE) return -E2BIG; @@ -7375,7 +7377,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); wrqu->data.length = strlen(priv->nick) + 1; memcpy(extra, priv->nick, wrqu->data.length); @@ -7390,7 +7392,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); u32 target_rate = wrqu->bitrate.value; u32 rate; int err = 0; @@ -7431,7 +7433,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int val; int len = sizeof(val); int err = 0; @@ -7483,7 +7485,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int value, err; /* Auto RTS not yet supported */ @@ -7523,7 +7525,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); wrqu->rts.value = priv->rts_threshold & ~RTS_DISABLED; wrqu->rts.fixed = 1; /* no auto select */ @@ -7540,7 +7542,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int err = 0, value; if (priv->ieee->iw_mode != IW_MODE_ADHOC) @@ -7580,7 +7582,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); if (priv->ieee->iw_mode != IW_MODE_ADHOC) { wrqu->power.disabled = 1; @@ -7616,7 +7618,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); if (!wrqu->frag.fixed) return -EINVAL; @@ -7646,7 +7648,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); wrqu->frag.value = priv->frag_threshold & ~FRAG_DISABLED; wrqu->frag.fixed = 0; /* no auto select */ wrqu->frag.disabled = (priv->frag_threshold & FRAG_DISABLED) ? 1 : 0; @@ -7660,7 +7662,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int err = 0; if (wrqu->retry.flags & IW_RETRY_LIFETIME || @@ -7709,7 +7711,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); wrqu->retry.disabled = 0; /* can't be disabled */ @@ -7738,7 +7740,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int err = 0; down(&priv->action_sem); @@ -7769,7 +7771,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); return ieee80211_wx_get_scan(priv->ieee, info, wrqu, extra); } @@ -7785,7 +7787,7 @@ * No check of STATUS_INITIALIZED required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); return ieee80211_wx_set_encode(priv->ieee, info, wrqu, key); } @@ -7797,7 +7799,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); return ieee80211_wx_get_encode(priv->ieee, info, wrqu, key); } @@ -7805,7 +7807,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int err = 0; down(&priv->action_sem); @@ -7855,7 +7857,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); if (!(priv->power_mode & IPW_POWER_ENABLED)) { wrqu->power.disabled = 1; @@ -7880,7 +7882,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int *parms = (int *)extra; int enable = (parms[0] > 0); int err = 0; @@ -7911,7 +7913,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); if (priv->status & STATUS_INITIALIZED) schedule_reset(priv); return 0; @@ -7923,7 +7925,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int err = 0, mode = *(int *)extra; down(&priv->action_sem); @@ -7951,7 +7953,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int level = IPW_POWER_LEVEL(priv->power_mode); s32 timeout, period; @@ -7988,7 +7990,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); int err, mode = *(int *)extra; down(&priv->action_sem); @@ -8021,7 +8023,7 @@ * This can be called at any time. No action lock required */ - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); if (priv->config & CFG_LONG_PREAMBLE) snprintf(wrqu->name, IFNAMSIZ, "long (1)"); @@ -8163,7 +8165,7 @@ int tx_qual; int beacon_qual; - struct ipw2100_priv *priv = ieee80211_priv(dev); + struct ipw2100_priv *priv = ieee80211_dev_to_priv(dev); struct iw_statistics *wstats; u32 rssi, quality, tx_retries, missed_beacons, tx_failures; u32 ord_len = sizeof(u32); Index: netdev/drivers/net/wireless/ipw2200.c =================================================================== --- netdev.orig/drivers/net/wireless/ipw2200.c 2005-06-01 11:03:37.000000000 +0200 +++ netdev/drivers/net/wireless/ipw2200.c 2005-06-03 11:57:33.000000000 +0200 @@ -5157,7 +5157,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); if (!(priv->status & STATUS_ASSOCIATED)) strcpy(wrqu->name, "unassociated"); else @@ -5210,7 +5210,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); struct iw_freq *fwrq = &wrqu->freq; /* if setting by freq convert to channel */ @@ -5244,7 +5244,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); wrqu->freq.e = 0; @@ -5264,7 +5264,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); int err = 0; IPW_DEBUG_WX("Set MODE: %d\n", wrqu->mode); @@ -5317,7 +5317,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); wrqu->mode = priv->ieee->iw_mode; IPW_DEBUG_WX("Get MODE -> %d\n", wrqu->mode); @@ -5354,7 +5354,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); struct iw_range *range = (struct iw_range *)extra; u16 val; int i; @@ -5418,7 +5418,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); static const unsigned char any[] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff @@ -5472,7 +5472,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); /* If we are associated, trying to associate, or have a statically * configured BSSID then return that; otherwise return ANY */ if (priv->config & CFG_STATIC_BSSID || @@ -5491,7 +5491,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); char *essid = ""; /* ANY */ int length = 0; @@ -5543,7 +5543,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); /* If we are associated, trying to associate, or have a statically * configured ESSID then return that; otherwise return ANY */ @@ -5567,7 +5567,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); IPW_DEBUG_WX("Setting nick to '%s'\n", extra); if (wrqu->data.length > IW_ESSID_MAX_SIZE) @@ -5586,7 +5586,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); IPW_DEBUG_WX("Getting nick\n"); wrqu->data.length = strlen(priv->nick) + 1; memcpy(extra, priv->nick, wrqu->data.length); @@ -5607,7 +5607,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv * priv = ieee80211_priv(dev); + struct ipw_priv * priv = ieee80211_dev_to_priv(dev); wrqu->bitrate.value = priv->last_rate; IPW_DEBUG_WX("GET Rate -> %d \n", wrqu->bitrate.value); @@ -5619,7 +5619,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); if (wrqu->rts.disabled) priv->rts_threshold = DEFAULT_RTS_THRESHOLD; @@ -5640,7 +5640,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); wrqu->rts.value = priv->rts_threshold; wrqu->rts.fixed = 0; /* no auto select */ wrqu->rts.disabled = @@ -5655,7 +5655,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); struct ipw_tx_power tx_power; int i; @@ -5699,7 +5699,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); wrqu->power.value = priv->tx_power; wrqu->power.fixed = 1; @@ -5717,7 +5717,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); if (wrqu->frag.disabled) priv->ieee->fts = DEFAULT_FTS; @@ -5738,7 +5738,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); wrqu->frag.value = priv->ieee->fts; wrqu->frag.fixed = 0; /* no auto select */ wrqu->frag.disabled = @@ -5771,7 +5771,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); IPW_DEBUG_WX("Start scan\n"); if (ipw_request_scan(priv)) return -EIO; @@ -5782,7 +5782,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); return ieee80211_wx_get_scan(priv->ieee, info, wrqu, extra); } @@ -5790,7 +5790,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *key) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); return ieee80211_wx_set_encode(priv->ieee, info, wrqu, key); } @@ -5798,7 +5798,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *key) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); return ieee80211_wx_get_encode(priv->ieee, info, wrqu, key); } @@ -5806,7 +5806,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); int err; if (wrqu->power.disabled) { @@ -5855,7 +5855,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); if (!(priv->power_mode & IPW_POWER_ENABLED)) { wrqu->power.disabled = 1; @@ -5872,7 +5872,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); int mode = *(int *)extra; int err; @@ -5900,7 +5900,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); int level = IPW_POWER_LEVEL(priv->power_mode); char *p = extra; @@ -5932,7 +5932,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); int mode = *(int *)extra; u8 band = 0, modulation = 0; @@ -5998,7 +5998,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); switch (priv->ieee->freq_band) { case IEEE80211_24GHZ_BAND: @@ -6046,7 +6046,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); int *parms = (int *)extra; int enable = (parms[0] > 0); @@ -6072,7 +6072,7 @@ struct iw_request_info *info, union iwreq_data *wrqu, char *extra) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); IPW_DEBUG_WX("RESET\n"); ipw_adapter_restart(priv); return 0; @@ -6185,7 +6185,7 @@ */ static struct iw_statistics *ipw_get_wireless_stats(struct net_device * dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); struct iw_statistics *wstats; wstats = &priv->wstats; @@ -6248,7 +6248,7 @@ static int ipw_net_open(struct net_device *dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); IPW_DEBUG_INFO("dev->open\n"); /* we should be verifying the device is ready to be opened */ if (!(priv->status & STATUS_RF_KILL_MASK) && @@ -6394,9 +6394,9 @@ } static int ipw_net_hard_start_xmit(struct ieee80211_txb *txb, - struct net_device *dev) + struct ieee80211_device *ieee) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(ieee); unsigned long flags; IPW_DEBUG_TX("dev->xmit(%d bytes)\n", txb->payload_size); @@ -6406,7 +6406,7 @@ if (!(priv->status & STATUS_ASSOCIATED)) { IPW_DEBUG_INFO("Tx attempt while not associated.\n"); priv->ieee->stats.tx_carrier_errors++; - netif_stop_queue(dev); + netif_stop_queue(ieee80211_dev(ieee)); goto fail_unlock; } @@ -6422,7 +6422,7 @@ static struct net_device_stats *ipw_net_get_stats(struct net_device *dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); priv->ieee->stats.tx_packets = priv->tx_packets; priv->ieee->stats.rx_packets = priv->rx_packets; @@ -6436,7 +6436,7 @@ static int ipw_net_set_mac_address(struct net_device *dev, void *p) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); struct sockaddr *addr = p; if (!is_valid_ether_addr(addr->sa_data)) return -EADDRNOTAVAIL; @@ -6451,7 +6451,7 @@ static void ipw_ethtool_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct ipw_priv *p = ieee80211_priv(dev); + struct ipw_priv *p = ieee80211_dev_to_priv(dev); char vers[64]; char date[32]; u32 len; @@ -6472,7 +6472,7 @@ static u32 ipw_ethtool_get_link(struct net_device *dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); return (priv->status & STATUS_ASSOCIATED) != 0; } @@ -6484,7 +6484,7 @@ static int ipw_ethtool_get_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom, u8 *bytes) { - struct ipw_priv *p = ieee80211_priv(dev); + struct ipw_priv *p = ieee80211_dev_to_priv(dev); if (eeprom->offset + eeprom->len > CX2_EEPROM_IMAGE_SIZE) return -EINVAL; @@ -6496,7 +6496,7 @@ static int ipw_ethtool_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom, u8 *bytes) { - struct ipw_priv *p = ieee80211_priv(dev); + struct ipw_priv *p = ieee80211_dev_to_priv(dev); int i; if (eeprom->offset + eeprom->len > CX2_EEPROM_IMAGE_SIZE) @@ -6633,10 +6633,10 @@ } -static void shim__set_security(struct net_device *dev, +static void shim__set_security(struct ieee80211_device *ieee, struct ieee80211_security *sec) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_priv(ieee); int i; for (i = 0; i < 4; i++) { @@ -6874,7 +6874,7 @@ /* Called by register_netdev() */ static int ipw_net_init(struct net_device *dev) { - struct ipw_priv *priv = ieee80211_priv(dev); + struct ipw_priv *priv = ieee80211_dev_to_priv(dev); if (priv->status & STATUS_RF_KILL_SW) { IPW_WARNING("Radio disabled by module parameter.\n"); @@ -6952,19 +6952,21 @@ { int err = 0; struct net_device *net_dev; + struct ieee80211_device *ieee; void __iomem *base; u32 length, val; struct ipw_priv *priv; int band, modulation; - net_dev = alloc_ieee80211(sizeof(struct ipw_priv)); - if (net_dev == NULL) { + ieee = alloc_ieee80211(sizeof(struct ipw_priv)); + if (ieee == NULL) { err = -ENOMEM; goto out; } + net_dev = ieee80211_dev(ieee); - priv = ieee80211_priv(net_dev); - priv->ieee = netdev_priv(net_dev); + priv = ieee80211_priv(ieee); + priv->ieee = ieee; priv->net_dev = net_dev; priv->pci_dev = pdev; #ifdef CONFIG_IPW_DEBUG @@ -7160,7 +7162,7 @@ pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); out_free_ieee80211: - free_ieee80211(priv->net_dev); + free_ieee80211(priv->ieee); out: return err; } @@ -7202,7 +7204,7 @@ pci_release_regions(pdev); pci_disable_device(pdev); pci_set_drvdata(pdev, NULL); - free_ieee80211(priv->net_dev); + free_ieee80211(priv->ieee); #ifdef CONFIG_PM if (fw_loaded) { -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:35:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:35:21 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GZGXq002144 for ; Fri, 3 Jun 2005 09:35:17 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 960F16282FC; Fri, 3 Jun 2005 18:34:18 +0200 (CEST) Date: Fri, 3 Jun 2005 18:34:18 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [6/9] ieee80211: ethernet independency Message-ID: <20050603183418.58c47b0c@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2032 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 38022 Lines: 1183 Makes the 802.11 layer independent of ethernet. (The previous implementation had the ethernet headers built by the ethernet layer and then parsed them and rebuilt them into 802.11 headers.) Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac Index: netdev/include/linux/netdevice.h =================================================================== --- netdev.orig/include/linux/netdevice.h 2005-06-01 11:05:01.000000000 +0200 +++ netdev/include/linux/netdevice.h 2005-06-03 13:21:00.000000000 +0200 @@ -83,13 +83,18 @@ * used. */ -#if !defined(CONFIG_AX25) && !defined(CONFIG_AX25_MODULE) && !defined(CONFIG_TR) +#if !defined(CONFIG_AX25) && !defined(CONFIG_AX25_MODULE) && !defined(CONFIG_TR) \ + && !defined(CONFIG_IEEE80211) #define LL_MAX_HEADER 32 #else #if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE) #define LL_MAX_HEADER 96 #else +#if defined(CONFIG_TR) #define LL_MAX_HEADER 48 +#else +#define LL_MAX_HEADER 38 +#endif #endif #endif Index: netdev/include/net/ieee80211.h =================================================================== --- netdev.orig/include/net/ieee80211.h 2005-06-03 13:20:46.000000000 +0200 +++ netdev/include/net/ieee80211.h 2005-06-03 13:21:00.000000000 +0200 @@ -20,7 +20,6 @@ */ #ifndef IEEE80211_H #define IEEE80211_H -#include /* ETH_ALEN */ #include /* ARRAY_SIZE */ #if WIRELESS_EXT < 17 @@ -42,25 +41,26 @@ WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */ +#define IEEE80211_ALEN 6 #define IEEE80211_HLEN 30 #define IEEE80211_FRAME_LEN (IEEE80211_DATA_LEN + IEEE80211_HLEN) struct ieee80211_hdr { u16 frame_ctl; u16 duration_id; - u8 addr1[ETH_ALEN]; - u8 addr2[ETH_ALEN]; - u8 addr3[ETH_ALEN]; + u8 addr1[IEEE80211_ALEN]; + u8 addr2[IEEE80211_ALEN]; + u8 addr3[IEEE80211_ALEN]; u16 seq_ctl; - u8 addr4[ETH_ALEN]; + u8 addr4[IEEE80211_ALEN]; } __attribute__ ((packed)); struct ieee80211_hdr_3addr { u16 frame_ctl; u16 duration_id; - u8 addr1[ETH_ALEN]; - u8 addr2[ETH_ALEN]; - u8 addr3[ETH_ALEN]; + u8 addr1[IEEE80211_ALEN]; + u8 addr2[IEEE80211_ALEN]; + u8 addr3[IEEE80211_ALEN]; u16 seq_ctl; } __attribute__ ((packed)); @@ -233,7 +233,7 @@ #define ETH_P_PREAUTH 0x88C7 /* IEEE 802.11i pre-authentication */ #ifndef ETH_P_80211_RAW -#define ETH_P_80211_RAW (ETH_P_ECONET + 1) +#define ETH_P_80211_RAW 0x0003 #endif /* IEEE 802.11 defines */ @@ -246,11 +246,29 @@ u8 ssap; /* always 0xAA */ u8 ctrl; /* always 0x03 */ u8 oui[P80211_OUI_LEN]; /* organizational universal id */ + u16 type; /* packet type ID field */ } __attribute__ ((packed)); #define SNAP_SIZE sizeof(struct ieee80211_snap_hdr) +#define IEEE80211_SNAP_IS_RFC1042(snap) \ + ((snap)->oui[0] == 0 && (snap)->oui[1] == 0 && (snap)->oui[2] == 0) +#define IEEE80211_SNAP_IS_BRIDGE_TUNNEL(snap) \ + ((snap)->oui[0] == 0 && (snap)->oui[1] == 0 && (snap)->oui[2] == 0xf8) + +#define IEEE80211_FC_GET_TODS(hdr) \ + ((hdr)->frame_ctl & __constant_cpu_to_le16(IEEE80211_FCTL_TODS)) +#define IEEE80211_FC_GET_FROMDS(hdr) \ + ((hdr)->frame_ctl & __constant_cpu_to_le16(IEEE80211_FCTL_FROMDS)) +#define IEEE80211_GET_DADDR(hdr) \ + (IEEE80211_FC_GET_TODS(hdr) ? (hdr)->addr3 : (hdr)->addr1) +#define IEEE80211_GET_SADDR(hdr) \ + (IEEE80211_FC_GET_FROMDS(hdr) ? \ + (IEEE80211_FC_GET_TODS(hdr) ? (hdr)->addr4 : (hdr)->addr3) \ + : (hdr)->addr2) +/* IEEE80211_GET_xADDR do not work when both TODS and FROMDS are set. */ + #define WLAN_FC_GET_TYPE(fc) ((fc) & IEEE80211_FCTL_FTYPE) #define WLAN_FC_GET_STYPE(fc) ((fc) & IEEE80211_FCTL_STYPE) @@ -395,8 +413,8 @@ unsigned int seq; unsigned int last_frag; struct sk_buff *skb; - u8 src_addr[ETH_ALEN]; - u8 dst_addr[ETH_ALEN]; + u8 src_addr[IEEE80211_ALEN]; + u8 dst_addr[IEEE80211_ALEN]; }; struct ieee80211_stats { @@ -507,7 +525,7 @@ u16 auth_sequence; u16 beacon_interval; u16 capability; - u8 current_ap[ETH_ALEN]; + u8 current_ap[IEEE80211_ALEN]; u16 listen_interval; struct { u16 association_id:14, reserved:2; @@ -537,7 +555,7 @@ struct ieee80211_assoc_request_frame { u16 capability; u16 listen_interval; - u8 current_ap[ETH_ALEN]; + u8 current_ap[IEEE80211_ALEN]; struct ieee80211_info_element info_element; } __attribute__ ((packed)); @@ -581,7 +599,7 @@ struct ieee80211_network { /* These entries are used to identify a unique network */ - u8 bssid[ETH_ALEN]; + u8 bssid[IEEE80211_ALEN]; u8 channel; /* Ensure null-terminated for any debug msgs */ u8 ssid[IW_ESSID_MAX_SIZE + 1]; @@ -625,12 +643,12 @@ #define MAC_ARG(x) ((u8*)(x))[0],((u8*)(x))[1],((u8*)(x))[2],((u8*)(x))[3],((u8*)(x))[4],((u8*)(x))[5] -extern inline int is_multicast_ether_addr(const u8 *addr) +extern inline int is_multicast_ieee80211_addr(const u8 *addr) { return ((addr[0] != 0xff) && (0x01 & addr[0])); } -extern inline int is_broadcast_ether_addr(const u8 *addr) +extern inline int is_broadcast_ieee80211_addr(const u8 *addr) { return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) && \ (addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff)); @@ -694,7 +712,7 @@ u16 fts; /* Fragmentation Threshold */ /* Association info */ - u8 bssid[ETH_ALEN]; + u8 bssid[IEEE80211_ALEN]; enum ieee80211_state state; @@ -783,7 +801,7 @@ return 0; } -extern inline int ieee80211_get_hdrlen(u16 fc) +extern inline int __ieee80211_get_hdrlen(u16 fc) { int hdrlen = IEEE80211_3ADDR_LEN; @@ -807,12 +825,29 @@ return hdrlen; } +#define ieee80211_get_hdrlen(hdr) __ieee80211_get_hdrlen(le16_to_cpu((hdr)->frame_ctl)) +#define IEEE80211_GET_DATA_HDR_LEN(hdr) \ + ((((hdr)->frame_ctl & \ + __constant_cpu_to_le16(IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) \ + == __constant_cpu_to_le16(IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) \ + ? IEEE80211_4ADDR_LEN : IEEE80211_3ADDR_LEN) +#define IEEE80211_GET_SNAP(hdr) \ + ((struct ieee80211_snap_hdr *) \ + ((u8 *)(hdr) + IEEE80211_GET_DATA_HDR_LEN(hdr))) + +extern inline int ieee80211_get_proto(struct ieee80211_hdr *header) +{ + struct ieee80211_snap_hdr *snap = IEEE80211_GET_SNAP(header); + return (snap->dsap == 0xaa && snap->ssap == 0xaa ? + ntohs(snap->type) : ETH_P_802_2); +} /* ieee80211.c */ extern void free_ieee80211(struct ieee80211_device *ieee); extern struct ieee80211_device *alloc_ieee80211(int sizeof_priv); +extern void ieee80211_setup(struct net_device *dev); extern int ieee80211_set_encryption(struct ieee80211_device *ieee); Index: netdev/net/ieee80211/ieee80211_rx.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_rx.c 2005-06-03 13:20:46.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_rx.c 2005-06-03 13:21:00.000000000 +0200 @@ -41,11 +41,10 @@ struct ieee80211_rx_stats *rx_stats) { struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; - u16 fc = le16_to_cpu(hdr->frame_ctl); skb->dev = ieee->dev; skb->mac.raw = skb->data; - skb_pull(skb, ieee80211_get_hdrlen(fc)); + skb_pull(skb, ieee80211_get_hdrlen(hdr)); skb->pkt_type = PACKET_OTHERHOST; skb->protocol = __constant_htons(ETH_P_80211_RAW); memset(skb->cb, 0, sizeof(skb->cb)); @@ -75,8 +74,8 @@ if (entry->skb != NULL && entry->seq == seq && (entry->last_frag + 1 == frag || frag == -1) && - memcmp(entry->src_addr, src, ETH_ALEN) == 0 && - memcmp(entry->dst_addr, dst, ETH_ALEN) == 0) + memcmp(entry->src_addr, src, IEEE80211_ALEN) == 0 && + memcmp(entry->dst_addr, dst, IEEE80211_ALEN) == 0) return entry; } @@ -103,7 +102,7 @@ sizeof(struct ieee80211_hdr) + 8 /* LLC */ + 2 /* alignment */ + - 8 /* WEP */ + ETH_ALEN /* WDS */); + 8 /* WEP */ + IEEE80211_ALEN /* WDS */); if (skb == NULL) return NULL; @@ -119,8 +118,8 @@ entry->seq = seq; entry->last_frag = frag; entry->skb = skb; - memcpy(entry->src_addr, hdr->addr2, ETH_ALEN); - memcpy(entry->dst_addr, hdr->addr1, ETH_ALEN); + memcpy(entry->src_addr, hdr->addr2, IEEE80211_ALEN); + memcpy(entry->dst_addr, hdr->addr1, IEEE80211_ALEN); } else { /* received a fragment of a frame for which the head fragment * should have already been received */ @@ -220,15 +219,6 @@ #endif -/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */ -/* Ethernet-II snap header (RFC1042 for most EtherTypes) */ -static unsigned char rfc1042_header[] = -{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 }; -/* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */ -static unsigned char bridge_tunnel_header[] = -{ 0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8 }; -/* No encapsulation header if EtherType < 0x600 (=length) */ - /* Called by ieee80211_rx_frame_decrypt */ static int ieee80211_is_eapol_frame(struct ieee80211_device *ieee, struct sk_buff *skb) @@ -236,7 +226,6 @@ struct net_device *dev = ieee80211_dev(ieee); u16 fc, ethertype; struct ieee80211_hdr *hdr; - u8 *pos; if (skb->len < 24) return 0; @@ -247,12 +236,12 @@ /* check that the frame is unicast frame to us */ if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_TODS && - memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0 && - memcmp(hdr->addr3, dev->dev_addr, ETH_ALEN) == 0) { + memcmp(hdr->addr1, dev->dev_addr, IEEE80211_ALEN) == 0 && + memcmp(hdr->addr3, dev->dev_addr, IEEE80211_ALEN) == 0) { /* ToDS frame with own addr BSSID and DA */ } else if ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_FROMDS && - memcmp(hdr->addr1, dev->dev_addr, ETH_ALEN) == 0) { + memcmp(hdr->addr1, dev->dev_addr, IEEE80211_ALEN) == 0) { /* FromDS frame with own addr as DA */ } else return 0; @@ -261,8 +250,7 @@ return 0; /* check for port access entity Ethernet type */ - pos = skb->data + 24; - ethertype = (pos[6] << 8) | pos[7]; + ethertype = ieee80211_get_proto(hdr); if (ethertype == ETH_P_PAE) return 1; @@ -281,7 +269,7 @@ return 0; hdr = (struct ieee80211_hdr *) skb->data; - hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + hdrlen = ieee80211_get_hdrlen(hdr); #ifdef CONFIG_IEEE80211_CRYPT_TKIP if (ieee->tkip_countermeasures && @@ -326,7 +314,7 @@ return 0; hdr = (struct ieee80211_hdr *) skb->data; - hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_ctl)); + hdrlen = ieee80211_get_hdrlen(hdr); atomic_inc(&crypt->refcnt); res = crypt->ops->decrypt_msdu(skb, keyidx, hdrlen, crypt->priv); @@ -342,6 +330,44 @@ } +unsigned short ieee80211_type_trans(struct sk_buff *skb, + struct ieee80211_device *ieee) +{ + struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; + struct ieee80211_snap_hdr *snap; + int hdrlen; + u8 *daddr = IEEE80211_GET_DADDR(hdr); + unsigned short type; + + skb->mac.raw = skb->data; + + hdrlen = ieee80211_get_hdrlen(hdr); + snap = (struct ieee80211_snap_hdr *)(skb->data + hdrlen); + if (snap->dsap == 0xaa && snap->ssap == 0xaa && + ((IEEE80211_SNAP_IS_RFC1042(snap) && + snap->type != __constant_htons(ETH_P_AARP) && + snap->type != __constant_htons(ETH_P_IPX)) || + IEEE80211_SNAP_IS_BRIDGE_TUNNEL(snap))) { + type = snap->type; + skb_pull(skb, hdrlen + SNAP_SIZE); + } + else { + type = __constant_htons(ETH_P_802_2); + skb_pull(skb, hdrlen); + } + + skb->input_dev = ieee->dev; + if (is_broadcast_ieee80211_addr(daddr)) + skb->pkt_type = PACKET_BROADCAST; + else if (is_multicast_ieee80211_addr(daddr)) + skb->pkt_type = PACKET_MULTICAST; + else if (memcmp(daddr, ieee->dev->dev_addr, IEEE80211_ALEN)) + skb->pkt_type = PACKET_OTHERHOST; + + return type; +} + + /* All received frames are sent to this function. @skb contains the frame in * IEEE 802.11 format, i.e., in the format it was sent over air. * This function is called only as a tasklet (software IRQ). */ @@ -354,8 +380,6 @@ u16 fc, type, stype, sc; struct net_device_stats *stats; unsigned int frag; - u8 *payload; - u16 ethertype; #ifdef NOT_YET struct net_device *wds = NULL; struct sk_buff *skb2 = NULL; @@ -364,8 +388,8 @@ int from_assoc_ap = 0; void *sta = NULL; #endif - u8 dst[ETH_ALEN]; - u8 src[ETH_ALEN]; + u8 dst[IEEE80211_ALEN]; + u8 src[IEEE80211_ALEN]; struct ieee80211_crypt_data *crypt = NULL; int keyidx = 0; @@ -383,7 +407,7 @@ stype = WLAN_FC_GET_STYPE(fc); sc = le16_to_cpu(hdr->seq_ctl); frag = WLAN_GET_SEQ_FRAG(sc); - hdrlen = ieee80211_get_hdrlen(fc); + hdrlen = __ieee80211_get_hdrlen(fc); #ifdef NOT_YET #if WIRELESS_EXT > 15 @@ -479,22 +503,23 @@ switch (fc & (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { case IEEE80211_FCTL_FROMDS: - memcpy(dst, hdr->addr1, ETH_ALEN); - memcpy(src, hdr->addr3, ETH_ALEN); + memcpy(dst, hdr->addr1, IEEE80211_ALEN); + memcpy(src, hdr->addr3, IEEE80211_ALEN); break; case IEEE80211_FCTL_TODS: - memcpy(dst, hdr->addr3, ETH_ALEN); - memcpy(src, hdr->addr2, ETH_ALEN); + memcpy(dst, hdr->addr3, IEEE80211_ALEN); + memcpy(src, hdr->addr2, IEEE80211_ALEN); break; case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: if (skb->len < IEEE80211_4ADDR_LEN) goto rx_dropped; - memcpy(dst, hdr->addr3, ETH_ALEN); - memcpy(src, hdr->addr4, ETH_ALEN); + memcpy(dst, hdr->addr3, IEEE80211_ALEN); + memcpy(src, hdr->addr4, IEEE80211_ALEN); + /* FIXME: this is wrong */ break; case 0: - memcpy(dst, hdr->addr1, ETH_ALEN); - memcpy(src, hdr->addr2, ETH_ALEN); + memcpy(dst, hdr->addr1, IEEE80211_ALEN); + memcpy(src, hdr->addr2, IEEE80211_ALEN); break; } @@ -509,7 +534,7 @@ if (ieee->iw_mode == IW_MODE_MASTER && !wds && (fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == IEEE80211_FCTL_FROMDS && ieee->stadev && - memcmp(hdr->addr2, ieee->assoc_ap_addr, ETH_ALEN) == 0) { + memcmp(hdr->addr2, ieee->assoc_ap_addr, IEEE80211_ALEN) == 0) { /* Frame from BSSID of the AP for which we are a client */ skb->dev = dev = ieee->stadev; stats = hostap_get_stats(dev); @@ -667,9 +692,6 @@ /* skb: hdr + (possible reassembled) full plaintext payload */ - payload = skb->data + hdrlen; - ethertype = (payload[6] << 8) | payload[7]; - #ifdef NOT_YET /* If IEEE 802.1X is used, check whether the port is authorized to send * the received frame. */ @@ -696,38 +718,6 @@ } #endif - /* convert hdr + possible LLC headers into Ethernet header */ - if (skb->len - hdrlen >= 8 && - ((memcmp(payload, rfc1042_header, SNAP_SIZE) == 0 && - ethertype != ETH_P_AARP && ethertype != ETH_P_IPX) || - memcmp(payload, bridge_tunnel_header, SNAP_SIZE) == 0)) { - /* remove RFC1042 or Bridge-Tunnel encapsulation and - * replace EtherType */ - skb_pull(skb, hdrlen + SNAP_SIZE); - memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); - memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); - } else { - u16 len; - /* Leave Ethernet header part of hdr and full payload */ - skb_pull(skb, hdrlen); - len = htons(skb->len); - memcpy(skb_push(skb, 2), &len, 2); - memcpy(skb_push(skb, ETH_ALEN), src, ETH_ALEN); - memcpy(skb_push(skb, ETH_ALEN), dst, ETH_ALEN); - } - -#ifdef NOT_YET - if (wds && ((fc & (IEEE80211_FCTL_TODS | IEEE80211_FCTL_FROMDS)) == - IEEE80211_FCTL_TODS) && - skb->len >= ETH_HLEN + ETH_ALEN) { - /* Non-standard frame: get addr4 from its bogus location after - * the payload */ - memcpy(skb->data + ETH_ALEN, - skb->data + skb->len - ETH_ALEN, ETH_ALEN); - skb_trim(skb, skb->len - ETH_ALEN); - } -#endif - stats->rx_packets++; stats->rx_bytes += skb->len; @@ -753,7 +743,7 @@ if (skb2 != NULL) { /* send to wireless media */ - skb2->protocol = __constant_htons(ETH_P_802_3); + skb2->protocol = ieee80211_type_trans(skb2, ieee); skb2->mac.raw = skb2->nh.raw = skb2->data; /* skb2->nh.raw = skb2->data + ETH_HLEN; */ skb2->dev = dev; @@ -763,7 +753,7 @@ #endif if (skb) { - skb->protocol = eth_type_trans(skb, dev); + skb->protocol = ieee80211_type_trans(skb, ieee); memset(skb->cb, 0, sizeof(skb->cb)); skb->dev = dev; skb->ip_summed = CHECKSUM_NONE; /* 802.11 crc not sufficient */ @@ -820,7 +810,7 @@ u8 i; /* Pull out fixed field data */ - memcpy(network->bssid, beacon->header.addr3, ETH_ALEN); + memcpy(network->bssid, beacon->header.addr3, IEEE80211_ALEN); network->capability = beacon->capability; network->last_scanned = jiffies; network->time_stamp[0] = beacon->time_stamp[0]; @@ -848,7 +838,7 @@ while (left >= sizeof(struct ieee80211_info_element_hdr)) { if (sizeof(struct ieee80211_info_element_hdr) + info_element->len > left) { IEEE80211_DEBUG_SCAN("SCAN: parse failed: info_element->len + 2 > left : info_element->len+2=%d left=%d.\n", - info_element->len + sizeof(struct ieee80211_info_element), + info_element->len + (int)sizeof(struct ieee80211_info_element), left); return 1; } @@ -1016,7 +1006,7 @@ * as one network */ return ((src->ssid_len == dst->ssid_len) && (src->channel == dst->channel) && - !memcmp(src->bssid, dst->bssid, ETH_ALEN) && + !memcmp(src->bssid, dst->bssid, IEEE80211_ALEN) && !memcmp(src->ssid, dst->ssid, src->ssid_len)); } Index: netdev/net/ieee80211/ieee80211_module.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_module.c 2005-06-03 13:20:46.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_module.c 2005-06-03 13:21:00.000000000 +0200 @@ -47,7 +47,6 @@ #include #include #include -#include #include #include @@ -102,24 +101,22 @@ { struct ieee80211_device *ieee; struct net_device *dev; - int alloc_size; + int alloc_size; int err; IEEE80211_DEBUG_INFO("Initializing...\n"); - alloc_size = ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) - & ~NETDEV_ALIGN_CONST) - + sizeof_priv; - dev = alloc_etherdev(alloc_size); + alloc_size = ((sizeof(struct ieee80211_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST) + + sizeof_priv; + dev = alloc_netdev(alloc_size, "wlan%d", ieee80211_setup); if (!dev) { - IEEE80211_ERROR("Unable to network device.\n"); + IEEE80211_ERROR("Unable to allocate network device.\n"); goto failed; } ieee = netdev_priv(dev); ieee->dev = dev; ieee->priv = ieee80211_priv(ieee); - - dev->hard_start_xmit = ieee80211_xmit; err = ieee80211_networks_allocate(ieee); if (err) { Index: netdev/net/ieee80211/ieee80211_tx.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_tx.c 2005-06-03 13:20:46.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_tx.c 2005-06-03 13:21:00.000000000 +0200 @@ -83,16 +83,6 @@ Total: 8 non-data bytes -802.3 Ethernet Data Frame - - ,-----------------------------------------. -Bytes | 6 | 6 | 2 | Variable | 4 | - |-------|-------|------|-----------|------| -Desc. | Dest. | Source| Type | IP Packet | fcs | - | MAC | MAC | | | | - `-----------------------------------------' -Total: 18 non-data bytes - In the event that fragmentation is required, the incoming payload is split into N parts of size ieee->fts. The first fragment contains the SNAP header and the remaining packets are just data. @@ -103,56 +93,8 @@ encryption it will take 3 frames. With WEP it will take 4 frames as the payload of each frame is reduced to 492 bytes. -* SKB visualization -* -* ,- skb->data -* | -* | ETHERNET HEADER ,-<-- PAYLOAD -* | | 14 bytes from skb->data -* | 2 bytes for Type --> ,T. | (sizeof ethhdr) -* | | | | -* |,-Dest.--. ,--Src.---. | | | -* | 6 bytes| | 6 bytes | | | | -* v | | | | | | -* 0 | v 1 | v | v 2 -* 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 -* ^ | ^ | ^ | -* | | | | | | -* | | | | `T' <---- 2 bytes for Type -* | | | | -* | | '---SNAP--' <-------- 6 bytes for SNAP -* | | -* `-IV--' <-------------------- 4 bytes for IV (WEP) -* -* SNAP HEADER -* */ -static u8 P802_1H_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0xf8 }; -static u8 RFC1042_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0x00 }; - -static inline int ieee80211_put_snap(u8 *data, u16 h_proto) -{ - struct ieee80211_snap_hdr *snap; - u8 *oui; - - snap = (struct ieee80211_snap_hdr *)data; - snap->dsap = 0xaa; - snap->ssap = 0xaa; - snap->ctrl = 0x03; - - if (h_proto == 0x8137 || h_proto == 0x80f3) - oui = P802_1H_OUI; - else - oui = RFC1042_OUI; - snap->oui[0] = oui[0]; - snap->oui[1] = oui[1]; - snap->oui[2] = oui[2]; - - *(u16 *)(data + SNAP_SIZE) = htons(h_proto); - - return SNAP_SIZE + sizeof(u16); -} static inline int ieee80211_encrypt_fragment( struct ieee80211_device *ieee, @@ -247,19 +189,16 @@ struct net_device *dev) { struct ieee80211_device *ieee = netdev_priv(dev); + struct ieee80211_hdr *header = (struct ieee80211_hdr *)skb->data; struct ieee80211_txb *txb = NULL; struct ieee80211_hdr *frag_hdr; int i, bytes_per_frag, nr_frags, bytes_last_frag, frag_size; unsigned long flags; struct net_device_stats *stats = &ieee->stats; - int ether_type, encrypt; + int type, encrypt; int bytes, fc, hdr_len; struct sk_buff *skb_frag; - struct ieee80211_hdr header = { /* Ensure zero initialized */ - .duration_id = 0, - .seq_ctl = 0 - }; - u8 dest[ETH_ALEN], src[ETH_ALEN]; + u8 *dest; struct ieee80211_crypt_data* crypt; @@ -268,76 +207,48 @@ /* If there is no driver handler to take the TXB, dont' bother * creating it... */ if (!ieee->hard_start_xmit) { - printk(KERN_WARNING "%s: No xmit handler.\n", - dev->name); + if (printk_ratelimit()) + printk(KERN_WARNING "%s: No xmit handler.\n", + dev->name); goto success; } - if (unlikely(skb->len < SNAP_SIZE + sizeof(u16))) { - printk(KERN_WARNING "%s: skb too small (%d).\n", - dev->name, skb->len); - goto success; - } - - ether_type = ntohs(((struct ethhdr *)skb->data)->h_proto); + type = ieee80211_get_proto(header); + dest = IEEE80211_GET_DADDR(header); + hdr_len = ieee80211_get_hdrlen(header); crypt = ieee->crypt[ieee->tx_keyidx]; - encrypt = !(ether_type == ETH_P_PAE && ieee->ieee802_1x) && + encrypt = !(type == ETH_P_PAE && ieee->ieee802_1x) && ieee->host_encrypt && crypt && crypt->ops; if (!encrypt && ieee->ieee802_1x && - ieee->drop_unencrypted && ether_type != ETH_P_PAE) { + ieee->drop_unencrypted && type != ETH_P_PAE) { stats->tx_dropped++; goto success; } #ifdef CONFIG_IEEE80211_DEBUG - if (crypt && !encrypt && ether_type == ETH_P_PAE) { - struct eapol *eap = (struct eapol *)(skb->data + - sizeof(struct ethhdr) - SNAP_SIZE - sizeof(u16)); + if (crypt && !encrypt && type == ETH_P_PAE) { + struct eapol *eap = (struct eapol *)(skb->data + hdr_len); IEEE80211_DEBUG_EAP("TX: IEEE 802.11 EAPOL frame: %s\n", eap_get_type(eap->type)); } #endif - /* Save source and destination addresses */ - memcpy(&dest, skb->data, ETH_ALEN); - memcpy(&src, skb->data+ETH_ALEN, ETH_ALEN); - - /* Advance the SKB to the start of the payload */ - skb_pull(skb, sizeof(struct ethhdr)); - /* Determine total amount of storage required for TXB packets */ - bytes = skb->len + SNAP_SIZE + sizeof(u16); + bytes = skb->len - hdr_len; + fc = le16_to_cpu(header->frame_ctl); if (encrypt) - fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA | - IEEE80211_FCTL_WEP; - else - fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + fc |= IEEE80211_FCTL_WEP; - if (ieee->iw_mode == IW_MODE_INFRA) { - fc |= IEEE80211_FCTL_TODS; - /* To DS: Addr1 = BSSID, Addr2 = SA, - Addr3 = DA */ - memcpy(&header.addr1, ieee->bssid, ETH_ALEN); - memcpy(&header.addr2, &src, ETH_ALEN); - memcpy(&header.addr3, &dest, ETH_ALEN); - } else if (ieee->iw_mode == IW_MODE_ADHOC) { - /* not From/To DS: Addr1 = DA, Addr2 = SA, - Addr3 = BSSID */ - memcpy(&header.addr1, dest, ETH_ALEN); - memcpy(&header.addr2, src, ETH_ALEN); - memcpy(&header.addr3, ieee->bssid, ETH_ALEN); - } - header.frame_ctl = cpu_to_le16(fc); - hdr_len = IEEE80211_3ADDR_LEN; + header->frame_ctl = cpu_to_le16(fc); /* Determine fragmentation size based on destination (multicast * and broadcast are not fragmented) */ - if (is_multicast_ether_addr(dest) || - is_broadcast_ether_addr(dest)) + if (is_multicast_ieee80211_addr(dest) || + is_broadcast_ieee80211_addr(dest)) frag_size = MAX_FRAG_THRESHOLD; else frag_size = ieee->fts; @@ -346,7 +257,7 @@ * this stack is providing the full 802.11 header, one will * eventually be affixed to this fragment -- so we must account for * it when determining the amount of payload space. */ - bytes_per_frag = frag_size - IEEE80211_3ADDR_LEN; + bytes_per_frag = frag_size - hdr_len; if (ieee->config & (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) bytes_per_frag -= IEEE80211_FCS_LEN; @@ -377,6 +288,8 @@ txb->encrypted = encrypt; txb->payload_size = bytes; + skb_pull(skb, hdr_len); + for (i = 0; i < nr_frags; i++) { skb_frag = txb->fragments[i]; @@ -384,7 +297,7 @@ skb_reserve(skb_frag, crypt->ops->extra_prefix_len); frag_hdr = (struct ieee80211_hdr *)skb_put(skb_frag, hdr_len); - memcpy(frag_hdr, &header, hdr_len); + memcpy(frag_hdr, header, hdr_len); /* If this is not the last fragment, then add the MOREFRAGS * bit to the frame control */ @@ -397,14 +310,6 @@ bytes = bytes_last_frag; } - /* Put a SNAP header on the first fragment */ - if (i == 0) { - ieee80211_put_snap( - skb_put(skb_frag, SNAP_SIZE + sizeof(u16)), - ether_type); - bytes -= SNAP_SIZE + sizeof(u16); - } - memcpy(skb_put(skb_frag, bytes), skb->data, bytes); /* Advance the SKB... */ Index: netdev/net/ieee80211/ieee80211_wx.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_wx.c 2005-06-03 13:20:46.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_wx.c 2005-06-03 13:21:00.000000000 +0200 @@ -53,7 +53,7 @@ /* First entry *MUST* be the AP MAC address */ iwe.cmd = SIOCGIWAP; iwe.u.ap_addr.sa_family = ARPHRD_ETHER; - memcpy(iwe.u.ap_addr.sa_data, network->bssid, ETH_ALEN); + memcpy(iwe.u.ap_addr.sa_data, network->bssid, IEEE80211_ALEN); start = iwe_stream_add_event(start, stop, &iwe, IW_EV_ADDR_LEN); /* Remaining entries will be displayed in the order we provide them */ Index: netdev/net/ieee80211/ieee80211_crypt_ccmp.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_crypt_ccmp.c 2005-06-01 11:05:14.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_crypt_ccmp.c 2005-06-03 13:21:00.000000000 +0200 @@ -17,7 +17,6 @@ #include #include #include -#include #include #include #include @@ -156,7 +155,7 @@ * Dlen */ b0[0] = 0x59; b0[1] = qc; - memcpy(b0 + 2, hdr->addr2, ETH_ALEN); + memcpy(b0 + 2, hdr->addr2, IEEE80211_ALEN); memcpy(b0 + 8, pn, CCMP_PN_LEN); b0[14] = (dlen >> 8) & 0xff; b0[15] = dlen & 0xff; @@ -173,13 +172,13 @@ aad[1] = aad_len & 0xff; aad[2] = pos[0] & 0x8f; aad[3] = pos[1] & 0xc7; - memcpy(aad + 4, hdr->addr1, 3 * ETH_ALEN); + memcpy(aad + 4, hdr->addr1, 3 * IEEE80211_ALEN); pos = (u8 *) &hdr->seq_ctl; aad[22] = pos[0] & 0x0f; aad[23] = 0; /* all bits masked */ memset(aad + 24, 0, 8); if (a4_included) - memcpy(aad + 24, hdr->addr4, ETH_ALEN); + memcpy(aad + 24, hdr->addr4, IEEE80211_ALEN); if (qc_included) { aad[a4_included ? 30 : 24] = qc; /* rest of QC masked */ Index: netdev/net/ieee80211/ieee80211_crypt_tkip.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_crypt_tkip.c 2005-06-01 11:05:14.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_crypt_tkip.c 2005-06-03 13:21:00.000000000 +0200 @@ -17,7 +17,6 @@ #include #include #include -#include #include #include @@ -461,20 +460,20 @@ switch (le16_to_cpu(hdr11->frame_ctl) & (IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) { case IEEE80211_FCTL_TODS: - memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ - memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + memcpy(hdr, hdr11->addr3, IEEE80211_ALEN); /* DA */ + memcpy(hdr + IEEE80211_ALEN, hdr11->addr2, IEEE80211_ALEN); /* SA */ break; case IEEE80211_FCTL_FROMDS: - memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ - memcpy(hdr + ETH_ALEN, hdr11->addr3, ETH_ALEN); /* SA */ + memcpy(hdr, hdr11->addr1, IEEE80211_ALEN); /* DA */ + memcpy(hdr + IEEE80211_ALEN, hdr11->addr3, IEEE80211_ALEN); /* SA */ break; case IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS: - memcpy(hdr, hdr11->addr3, ETH_ALEN); /* DA */ - memcpy(hdr + ETH_ALEN, hdr11->addr4, ETH_ALEN); /* SA */ + memcpy(hdr, hdr11->addr3, IEEE80211_ALEN); /* DA */ + memcpy(hdr + IEEE80211_ALEN, hdr11->addr4, IEEE80211_ALEN); /* SA */ break; case 0: - memcpy(hdr, hdr11->addr1, ETH_ALEN); /* DA */ - memcpy(hdr + ETH_ALEN, hdr11->addr2, ETH_ALEN); /* SA */ + memcpy(hdr, hdr11->addr1, IEEE80211_ALEN); /* DA */ + memcpy(hdr + IEEE80211_ALEN, hdr11->addr2, IEEE80211_ALEN); /* SA */ break; } @@ -521,7 +520,7 @@ else ev.flags |= IW_MICFAILURE_PAIRWISE; ev.src_addr.sa_family = ARPHRD_ETHER; - memcpy(ev.src_addr.sa_data, hdr->addr2, ETH_ALEN); + memcpy(ev.src_addr.sa_data, hdr->addr2, IEEE80211_ALEN); memset(&wrqu, 0, sizeof(wrqu)); wrqu.data.length = sizeof(ev); wireless_send_event(dev, IWEVMICHAELMICFAILURE, &wrqu, (char *) &ev); Index: netdev/net/ieee80211/Makefile =================================================================== --- netdev.orig/net/ieee80211/Makefile 2005-06-01 11:05:14.000000000 +0200 +++ netdev/net/ieee80211/Makefile 2005-06-03 13:21:00.000000000 +0200 @@ -5,6 +5,7 @@ obj-$(CONFIG_IEEE80211_CRYPT_TKIP) += ieee80211_crypt_tkip.o ieee80211-objs := \ ieee80211_module.o \ + ieee80211_proto.o \ ieee80211_tx.o \ ieee80211_rx.o \ ieee80211_wx.o Index: netdev/net/ieee80211/ieee80211_proto.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ netdev/net/ieee80211/ieee80211_proto.c 2005-06-03 13:21:00.000000000 +0200 @@ -0,0 +1,239 @@ +/******************************************************************************* + + Copyright (c) 2005 Jiri Benc and Jirka Bohac + Copyright (c) 2004 Intel Corporation. All rights reserved. + (Contact: James P. Ketrenos ) + + Sponsored by SuSE. + + This program is free software; you can redistribute it and/or modify it + under the terms of version 2 of the GNU General Public License as + published by the Free Software Foundation. + + This program is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., 59 + Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +*******************************************************************************/ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +static int ieee80211_change_mtu(struct net_device *dev, int new_mtu) +{ + if ((new_mtu < 68) || (new_mtu > IEEE80211_DATA_LEN - 8 - SNAP_SIZE)) + return -EINVAL; + dev->mtu = new_mtu; + return 0; +} + + +static u8 P802_1H_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0xf8 }; +static u8 RFC1042_OUI[P80211_OUI_LEN] = { 0x00, 0x00, 0x00 }; + +static inline int __ieee80211_put_snap(u8 *data, u16 h_proto) +{ + struct ieee80211_snap_hdr *snap; + u8 *oui; + + snap = (struct ieee80211_snap_hdr *)data; + snap->dsap = 0xaa; + snap->ssap = 0xaa; + snap->ctrl = 0x03; + + if (h_proto == __constant_htons(ETH_P_IPX) || + h_proto == __constant_htons(ETH_P_AARP)) + oui = P802_1H_OUI; + else + oui = RFC1042_OUI; + snap->oui[0] = oui[0]; + snap->oui[1] = oui[1]; + snap->oui[2] = oui[2]; + + snap->type = h_proto; + + return SNAP_SIZE; +} + +static inline int ieee80211_put_snap(u8 *data, u16 h_proto) +{ + return __ieee80211_put_snap(data, htons(h_proto)); +} + +/* + * Create the IEEE 802.11 MAC header for an arbitrary protocol layer + * + * saddr=NULL means use device source address + * daddr=NULL means leave destination address (eg unresolved arp) + */ +static int ieee80211_header(struct sk_buff *skb, struct net_device *dev, + unsigned short type, void *daddr, void *saddr, unsigned len) +{ + struct ieee80211_device *ieee = netdev_priv(dev); + struct ieee80211_hdr *header; + int fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + int hdr_len = IEEE80211_3ADDR_LEN; + + if (type != ETH_P_802_3 && type != ETH_P_802_2) { + ieee80211_put_snap(skb_push(skb, SNAP_SIZE), type); + hdr_len += SNAP_SIZE; + } + + if (!saddr) saddr = dev->dev_addr; + header = (struct ieee80211_hdr *)skb_push(skb, IEEE80211_3ADDR_LEN); + header->duration_id = header->seq_ctl = 0; + if (ieee->iw_mode == IW_MODE_INFRA) { + fc |= IEEE80211_FCTL_TODS; + /* To DS: Addr1 = BSSID, Addr2 = SA, + Addr3 = DA */ + memcpy(header->addr1, ieee->bssid, IEEE80211_ALEN); + memcpy(header->addr2, saddr, IEEE80211_ALEN); + if (daddr) + memcpy(header->addr3, daddr, IEEE80211_ALEN); + else + memset(header->addr3, 0, IEEE80211_ALEN); + } else if (ieee->iw_mode == IW_MODE_ADHOC) { + /* not From/To DS: Addr1 = DA, Addr2 = SA, + Addr3 = BSSID */ + if (daddr) + memcpy(header->addr1, daddr, IEEE80211_ALEN); + else + memset(header->addr1, 0, IEEE80211_ALEN); + memcpy(header->addr2, saddr, IEEE80211_ALEN); + memcpy(header->addr3, ieee->bssid, IEEE80211_ALEN); + } + header->frame_ctl = cpu_to_le16(fc); + + if (!daddr || (dev->flags & (IFF_LOOPBACK | IFF_NOARP))) + return -hdr_len; + return hdr_len; +} + +static int ieee80211_rebuild_header(struct sk_buff *skb) +{ + struct ieee80211_hdr *header = (struct ieee80211_hdr *)skb->data; + struct net_device *dev = skb->dev; + unsigned short type; + + type = ieee80211_get_proto(header); + + switch (type) { +#ifdef CONFIG_INET + case ETH_P_IP: + return arp_find(IEEE80211_GET_DADDR(header), skb); +#endif + default: + printk(KERN_DEBUG + "%s: unable to resolve type %X addresses.\n", + dev->name, type); + break; + } + + return 0; +} + +static int ieee80211_mac_addr(struct net_device *dev, void *p) +{ + struct sockaddr *addr = p; + + if (netif_running(dev)) + return -EBUSY; + memcpy(dev->dev_addr, addr->sa_data, dev->addr_len); + return 0; +} + +static int ieee80211_header_cache(struct neighbour *neigh, struct hh_cache *hh) +{ + struct net_device *dev = neigh->dev; + struct ieee80211_device *ieee = netdev_priv(dev); + unsigned short type = hh->hh_type; + struct ieee80211_hdr *header; + int fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; + + if (type == __constant_htons(ETH_P_802_3) || + type == __constant_htons(ETH_P_802_2)) + return -1; + + header = (struct ieee80211_hdr *) + (((u8 *)hh->hh_data) + + (HH_DATA_OFF(IEEE80211_3ADDR_LEN + SNAP_SIZE))); + __ieee80211_put_snap((u8 *)header + IEEE80211_3ADDR_LEN, type); + + header->duration_id = header->seq_ctl = 0; + if (ieee->iw_mode == IW_MODE_INFRA) { + fc |= IEEE80211_FCTL_TODS; + /* To DS: Addr1 = BSSID, Addr2 = SA, + Addr3 = DA */ + memcpy(header->addr1, ieee->bssid, IEEE80211_ALEN); + memcpy(header->addr2, dev->dev_addr, IEEE80211_ALEN); + memcpy(header->addr3, neigh->ha, IEEE80211_ALEN); + } else if (ieee->iw_mode == IW_MODE_ADHOC) { + /* not From/To DS: Addr1 = DA, Addr2 = SA, + Addr3 = BSSID */ + memcpy(header->addr1, neigh->ha, IEEE80211_ALEN); + memcpy(header->addr2, dev->dev_addr, IEEE80211_ALEN); + memcpy(header->addr3, ieee->bssid, IEEE80211_ALEN); + } + header->frame_ctl = cpu_to_le16(fc); + + hh->hh_len = IEEE80211_3ADDR_LEN + SNAP_SIZE; + return 0; +} + +static void ieee80211_header_cache_update(struct hh_cache *hh, + struct net_device *dev, unsigned char *haddr) +{ + struct ieee80211_hdr *header; + + header = (struct ieee80211_hdr *) + (((u8 *)hh->hh_data) + + (HH_DATA_OFF(IEEE80211_3ADDR_LEN + SNAP_SIZE))); + memcpy(IEEE80211_GET_DADDR(header), haddr, dev->addr_len); +} + +static int ieee80211_header_parse(struct sk_buff *skb, unsigned char *haddr) +{ + struct ieee80211_hdr *header = (struct ieee80211_hdr *)skb->data; + + memcpy(haddr, IEEE80211_GET_SADDR(header), IEEE80211_ALEN); + return IEEE80211_ALEN; +} + + +void ieee80211_setup(struct net_device *dev) +{ + dev->change_mtu = ieee80211_change_mtu; + dev->hard_header = ieee80211_header; + dev->rebuild_header = ieee80211_rebuild_header; + dev->set_mac_address = ieee80211_mac_addr; + dev->hard_header_cache = ieee80211_header_cache; + dev->header_cache_update = ieee80211_header_cache_update; + dev->hard_header_parse = ieee80211_header_parse; + + dev->hard_start_xmit = ieee80211_xmit; + + dev->type = ARPHRD_ETHER; + dev->hard_header_len = IEEE80211_3ADDR_LEN + SNAP_SIZE; + dev->mtu = IEEE80211_DATA_LEN - 8 - SNAP_SIZE; + dev->addr_len = IEEE80211_ALEN; + dev->tx_queue_len = 1000; + dev->flags = IFF_BROADCAST | IFF_MULTICAST; + + memset(dev->broadcast, 0xFF, IEEE80211_ALEN); +} + + +EXPORT_SYMBOL(ieee80211_setup); -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:36:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:36:29 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GaPXq002608 for ; Fri, 3 Jun 2005 09:36:25 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 052A06282FC; Fri, 3 Jun 2005 18:35:27 +0200 (CEST) Date: Fri, 3 Jun 2005 18:35:26 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [7/9] ipw: fix after "ieee80211: ethernet independency" Message-ID: <20050603183526.0effd2b0@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2033 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 1866 Lines: 59 Fixes ipw2200 after making the ieee80211 layer independent of ethernet. Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac Index: netdev/drivers/net/wireless/ipw2200.c =================================================================== --- netdev.orig/drivers/net/wireless/ipw2200.c 2005-05-31 18:25:53.000000000 +0200 +++ netdev/drivers/net/wireless/ipw2200.c 2005-05-31 18:32:18.000000000 +0200 @@ -4920,8 +4920,8 @@ ETH_ALEN) || !memcmp(header->addr3, priv->bssid, ETH_ALEN) || - is_broadcast_ether_addr(header->addr1) || - is_multicast_ether_addr(header->addr1); + is_broadcast_ieee80211_addr(header->addr1) || + is_multicast_ieee80211_addr(header->addr1); break; case IW_MODE_INFRA: @@ -4932,8 +4932,8 @@ !memcmp(header->addr1, priv->net_dev->dev_addr, ETH_ALEN) || - is_broadcast_ether_addr(header->addr1) || - is_multicast_ether_addr(header->addr1); + is_broadcast_ieee80211_addr(header->addr1) || + is_multicast_ieee80211_addr(header->addr1); break; } @@ -6285,8 +6285,8 @@ switch (priv->ieee->iw_mode) { case IW_MODE_ADHOC: hdr_len = IEEE80211_3ADDR_LEN; - unicast = !is_broadcast_ether_addr(hdr->addr1) && - !is_multicast_ether_addr(hdr->addr1); + unicast = !is_broadcast_ieee80211_addr(hdr->addr1) && + !is_multicast_ieee80211_addr(hdr->addr1); id = ipw_find_station(priv, hdr->addr1); if (id == IPW_INVALID_STATION) { id = ipw_add_station(priv, hdr->addr1); @@ -6301,8 +6301,8 @@ case IW_MODE_INFRA: default: - unicast = !is_broadcast_ether_addr(hdr->addr3) && - !is_multicast_ether_addr(hdr->addr3); + unicast = !is_broadcast_ieee80211_addr(hdr->addr3) && + !is_multicast_ieee80211_addr(hdr->addr3); hdr_len = IEEE80211_3ADDR_LEN; id = 0; break; -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:37:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:37:21 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GbGXq003065 for ; Fri, 3 Jun 2005 09:37:16 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id 022006282FC; Fri, 3 Jun 2005 18:36:18 +0200 (CEST) Date: Fri, 3 Jun 2005 18:36:17 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [8/9] ieee80211: add sequence numbers Message-ID: <20050603183617.7903c5a0@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2034 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 2286 Lines: 72 Adds sequence numbers to IEEE 802.11 headers. Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac Index: netdev/include/net/ieee80211.h =================================================================== --- netdev.orig/include/net/ieee80211.h 2005-06-03 13:21:00.000000000 +0200 +++ netdev/include/net/ieee80211.h 2005-06-03 13:21:06.000000000 +0200 @@ -711,6 +711,8 @@ unsigned int frag_next_idx; u16 fts; /* Fragmentation Threshold */ + u16 seq_number; /* sequence number in transmitted frames */ + /* Association info */ u8 bssid[IEEE80211_ALEN]; Index: netdev/net/ieee80211/ieee80211_module.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_module.c 2005-06-03 13:21:00.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_module.c 2005-06-03 13:21:06.000000000 +0200 @@ -128,6 +128,7 @@ /* Default fragmentation threshold is maximum payload size */ ieee->fts = DEFAULT_FTS; + ieee->seq_number = 0; ieee->scan_age = DEFAULT_MAX_SCAN_AGE; ieee->open_wep = 1; Index: netdev/net/ieee80211/ieee80211_tx.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_tx.c 2005-06-03 13:21:00.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_tx.c 2005-06-03 13:21:06.000000000 +0200 @@ -276,6 +276,13 @@ else bytes_last_frag = bytes_per_frag; + if (nr_frags > 16) { + /* Should never happen */ + printk(KERN_WARNING "%s: Fragmentation threshold too low\n", + dev->name); + goto failed; + } + /* When we allocate the TXB we allocate enough space for the reserve * and full fragment bytes (bytes_per_frag doesn't include prefix, * postfix, header, FCS, etc.) */ @@ -299,6 +306,8 @@ frag_hdr = (struct ieee80211_hdr *)skb_put(skb_frag, hdr_len); memcpy(frag_hdr, header, hdr_len); + frag_hdr->seq_ctl = cpu_to_le16(ieee->seq_number | i); + /* If this is not the last fragment, then add the MOREFRAGS * bit to the frame control */ if (i != nr_frags - 1) { @@ -323,7 +332,7 @@ (CFG_IEEE80211_COMPUTE_FCS | CFG_IEEE80211_RESERVE_FCS)) skb_put(skb_frag, 4); } - + ieee->seq_number += 0x10; success: spin_unlock_irqrestore(&ieee->lock, flags); -- Jiri Benc SUSE Labs From jbenc@suse.cz Fri Jun 3 09:38:26 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 09:38:30 -0700 (PDT) Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53GcPXq003682 for ; Fri, 3 Jun 2005 09:38:25 -0700 Received: from griffin.suse.cz (griffin.suse.cz [10.20.1.99]) by mail.suse.cz (SUSE CR ESMTP Mailer) with ESMTP id C06036282FC; Fri, 3 Jun 2005 18:37:26 +0200 (CEST) Date: Fri, 3 Jun 2005 18:37:26 +0200 From: Jiri Benc To: NetDev Cc: Jeff Garzik , Jirka Bohac Subject: [9/9] ieee80211: ETH_P_802_11 ethertype Message-ID: <20050603183726.482a91d2@griffin.suse.cz> In-Reply-To: <20050603182625.64d33be3@griffin.suse.cz> References: <20050603182625.64d33be3@griffin.suse.cz> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2035 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jbenc@suse.cz Precedence: bulk X-list: netdev Content-Length: 3775 Lines: 110 Introduced new ETH_P_802_11 ethertype. Fixed ieee80211_type_trans() to return ETH_P_802_11 in case of non-data frame. Signed-off-by: Jiri Benc Signed-off-by: Jirka Bohac Index: netdev/include/linux/if_ether.h =================================================================== --- netdev.orig/include/linux/if_ether.h 2005-06-01 11:04:59.000000000 +0200 +++ netdev/include/linux/if_ether.h 2005-06-03 13:21:15.000000000 +0200 @@ -92,6 +92,7 @@ #define ETH_P_ECONET 0x0018 /* Acorn Econet */ #define ETH_P_HDLC 0x0019 /* HDLC frames */ #define ETH_P_ARCNET 0x001A /* 1A for ArcNet :-) */ +#define ETH_P_802_11 0x001B /* 802.11 frames */ /* * This is an Ethernet frame header. Index: netdev/include/net/ieee80211.h =================================================================== --- netdev.orig/include/net/ieee80211.h 2005-06-03 13:21:10.000000000 +0200 +++ netdev/include/net/ieee80211.h 2005-06-03 13:21:15.000000000 +0200 @@ -232,10 +232,6 @@ #define ETH_P_PREAUTH 0x88C7 /* IEEE 802.11i pre-authentication */ -#ifndef ETH_P_80211_RAW -#define ETH_P_80211_RAW 0x0003 -#endif - /* IEEE 802.11 defines */ #define P80211_OUI_LEN 3 Index: netdev/net/ieee80211/ieee80211_rx.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_rx.c 2005-06-03 13:21:00.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_rx.c 2005-06-03 13:21:15.000000000 +0200 @@ -46,7 +46,7 @@ skb->mac.raw = skb->data; skb_pull(skb, ieee80211_get_hdrlen(hdr)); skb->pkt_type = PACKET_OTHERHOST; - skb->protocol = __constant_htons(ETH_P_80211_RAW); + skb->protocol = __constant_htons(ETH_P_802_11); memset(skb->cb, 0, sizeof(skb->cb)); netif_rx(skb); } @@ -338,22 +338,33 @@ int hdrlen; u8 *daddr = IEEE80211_GET_DADDR(hdr); unsigned short type; + u16 fc; skb->mac.raw = skb->data; - hdrlen = ieee80211_get_hdrlen(hdr); - snap = (struct ieee80211_snap_hdr *)(skb->data + hdrlen); - if (snap->dsap == 0xaa && snap->ssap == 0xaa && - ((IEEE80211_SNAP_IS_RFC1042(snap) && - snap->type != __constant_htons(ETH_P_AARP) && - snap->type != __constant_htons(ETH_P_IPX)) || - IEEE80211_SNAP_IS_BRIDGE_TUNNEL(snap))) { - type = snap->type; - skb_pull(skb, hdrlen + SNAP_SIZE); + fc = le16_to_cpu(hdr->frame_ctl); + if (WLAN_FC_GET_TYPE(fc) == IEEE80211_FTYPE_DATA && + WLAN_FC_GET_STYPE(fc) == IEEE80211_STYPE_DATA) { + hdrlen = __ieee80211_get_hdrlen(fc); + snap = (struct ieee80211_snap_hdr *)(skb->data + hdrlen); + if (snap->dsap == 0xaa && snap->ssap == 0xaa && + ((IEEE80211_SNAP_IS_RFC1042(snap) && + snap->type != __constant_htons(ETH_P_AARP) && + snap->type != __constant_htons(ETH_P_IPX)) || + IEEE80211_SNAP_IS_BRIDGE_TUNNEL(snap))) { + type = snap->type; + skb_pull(skb, hdrlen + SNAP_SIZE); + } + else { + type = __constant_htons(ETH_P_802_2); + skb_pull(skb, hdrlen); + } } else { - type = __constant_htons(ETH_P_802_2); - skb_pull(skb, hdrlen); + /* If the type isn't data we want to keep the 802.11 header + * in place. + */ + type = __constant_htons(ETH_P_802_11); } skb->input_dev = ieee->dev; Index: netdev/net/ieee80211/ieee80211_proto.c =================================================================== --- netdev.orig/net/ieee80211/ieee80211_proto.c 2005-06-03 13:21:00.000000000 +0200 +++ netdev/net/ieee80211/ieee80211_proto.c 2005-06-03 13:21:15.000000000 +0200 @@ -87,6 +87,8 @@ int fc = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_DATA; int hdr_len = IEEE80211_3ADDR_LEN; + if (type == ETH_P_802_11) + return 0; if (type != ETH_P_802_3 && type != ETH_P_802_2) { ieee80211_put_snap(skb_push(skb, SNAP_SIZE), type); hdr_len += SNAP_SIZE; -- Jiri Benc SUSE Labs From mitch.a.williams@intel.com Fri Jun 3 10:45:41 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 10:45:45 -0700 (PDT) Received: from orsfmr003.jf.intel.com (fmr18.intel.com [134.134.136.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53HjeXq009108 for ; Fri, 3 Jun 2005 10:45:41 -0700 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j53HhWV5003802; Fri, 3 Jun 2005 17:43:32 GMT Received: from nwlxmail01.jf.intel.com (nwlxmail01.jf.intel.com [10.7.171.40]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id j53HhWSc004792; Fri, 3 Jun 2005 17:43:32 GMT Received: from mawilli1-desk2.amr.corp.intel.com (mawilli1-desk2.amr.corp.intel.com [134.134.3.124]) by nwlxmail01.jf.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id j53HhWSL028048; Fri, 3 Jun 2005 10:43:32 -0700 Date: Fri, 3 Jun 2005 10:43:32 -0700 From: Mitch Williams X-X-Sender: mawilli1@mawilli1-desk2.amr.corp.intel.com To: jamal cc: "David S. Miller" , "Ronciak, John" , jdmason@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch In-Reply-To: <1117765954.6095.49.camel@localhost.localdomain> Message-ID: References: <468F3FDA28AA87429AD807992E22D07E0450BFDB@orsmsx408> <20050602.171812.48807872.davem@davemloft.net> <1117765954.6095.49.camel@localhost.localdomain> ReplyTo: "Mitch Williams" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.44 X-archive-position: 2037 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch.a.williams@intel.com Precedence: bulk X-list: netdev Content-Length: 4153 Lines: 88 On Thu, 2 Jun 2005, jamal wrote: > > Heres what i think i saw as a flow of events: > Someone posted a theory that if you happen to reduce the weight > (iirc the reduction was via a shift) then the DRR would give less CPU > time cycle to the driver - Whats the big suprise there? thats DRR design > intent. Well, that was me. Or at least I was the original poster on this thread. But my theory (if you can call it that) really wasn't about CPU time. I spent several weeks in our lab with the somewhat nebulous task of "look at Linux performance". And what I found was, to me, counterintuitive: reducing weight improved performance, sometimes significantly. > > Stephen has a patch which allows people to reduce the weight. > DRR provides fairness. If you have 10 NICs coming at different wire > rates, the weights provide a fairness quota without caring about what > those speeds are. So it doesnt make any sense IMO to have the weight > based on what the NIC speed is. Infact i claim it is _nonsense_. You > dont need to factor speed. And the claim that DRR is not real world > is blasphemous. OK, well, call me a blasphemer (against whom?). I'm not really saying that the DRR algorithm is not real-world, but rather that NAPI as currently implemented has some significant performance limitations. In my mind, there are two major problems with NAPI as it stands today. First, at Gigabit and higher speeds, the default settings don't allow the driver to process received packets in a timely manner. This causes dropped packets due to lack of receive resources. Lowering the weight can fix this, at least in a single-adapter environment. Second, at 10Mbps and 100Mbps, modern processors are just too fast for the network. The NAPI polling loop runs so much quicker than the wire speed that only one or two packets are processed per softirq -- which effectively puts the adapter back in interrupt mode. Because of this, you can easily bog down a very fast box with relatively slow traffic, just due to the massive number of interrupts generated. My original post (and patch) were to address the first issue. By using the shift value on the quota, I effectively lowered the weight for every driver in the system. Stephen sent out a patch that allowed you to adjust each driver's weight individually. My testing has shown that, as expected, you can achieve the same performance gain either way. In a multiple-adapter environment, you need to adjust the weight of all drivers together to fix the dropped packets issue. Lowering the weight on one adapter won't help it if the other interfaces are still taking up a lot of time in their receive loops. My patch gave you one knob to twiddle that would correct this issue. Stephen's patch gave you one knob for each adapter, but now you need to twiddle them all to see any benefit. The second issue currently has no fix. What is needed is a way for the driver to request a delayed poll, possibly based on line speed. If we could wait, say, 8 packet times before polling, we could significantly reduce the number of interrupts the system has to deal with, at the cost of higher latency. We haven't had time to investigate this at all, but the need is clearly present -- we've had customer calls about this issue. > > Having said that: > I have a feeling that issue which is which is being waded around is the > amount that the softirq chews in the CPU (unfortunately a well known > issue) and to some extent the packet flow a specific driver chews > depending on the path it takes. I fiddled with this concept a little bit, but didn't see much performance gain by doing so. But it may be something that we can go back and look at. Either way, I think the netdev community needs to look critically at NAPI, and make some changes. Network performance in 2.6.12-rcWhatever is pretty poor. 2.4.30 beats it handily, and it really shouldn't be that way. > This, however, does not eradicate the need for DRR and is absolutely not > driver specific. Agreed. All of the changes I've experimented with at the NAPI level have affected performance similarly on multiple drivers. -Mitch From john.ronciak@intel.com Fri Jun 3 10:43:12 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 10:43:21 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53HhCXq008752 for ; Fri, 3 Jun 2005 10:43:12 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j53HepFT003163; Fri, 3 Jun 2005 17:40:51 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j53HeadQ026719; Fri, 3 Jun 2005 17:40:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005060310404812872 ; Fri, 03 Jun 2005 10:40:48 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 10:40:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC: NAPI packet weighting patch Date: Fri, 3 Jun 2005 10:40:47 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0450BFE6@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: NAPI packet weighting patch Thread-Index: AcVn0fHLt/WdosjHQo2U4D6fkFIrvwAkDmig From: "Ronciak, John" To: "David S. Miller" Cc: , , , "Williams, Mitch A" , , , "Venkatesan, Ganesh" , "Brandeburg, Jesse" X-OriginalArrivalTime: 03 Jun 2005 17:40:48.0018 (UTC) FILETIME=[60830F20:01C56863] X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j53HhCXq008752 X-archive-position: 2036 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: john.ronciak@intel.com Precedence: bulk X-list: netdev Content-Length: 899 Lines: 23 > What more do you need other than checking the statistics counter? The > drop statistics (the ones we care about) are incremented in real time > by the ->poll() code, so it's not like we have to trigger some > asynchronous event to get a current version of the number. > I think that there is some more confusion here. I'm talking about frames dropped by the Ethernet controller at the hardware level (no descriptor available). This for example is happening now with our driver with the weight set to 64. This is also what started us looking into what was going on with the weight. I don't see how the NAPI code to dynamically adjust the weight could easily get the hardware stats number to know if frames are being dropped or not. Sorry if I caused the confusion here. Mitch is working on a response to Jamal's last mail trying to level set what we are seeing and doing. Cheers, John From Robert.Olsson@data.slu.se Fri Jun 3 11:10:04 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 11:10:15 -0700 (PDT) Received: from mx1.slu.se (mx1.slu.se [130.238.96.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53IA3Xq010457 for ; Fri, 3 Jun 2005 11:10:04 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mx1.slu.se (8.13.1/8.13.1) with ESMTP id j53I8mkB020710; Fri, 3 Jun 2005 20:08:48 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 143BBEE3F0; Fri, 3 Jun 2005 20:08:48 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17056.40112.39108.32685@robur.slu.se> Date: Fri, 3 Jun 2005 20:08:48 +0200 To: "Ronciak, John" Cc: "David S. Miller" , , , , "Williams, Mitch A" , , , "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: RE: RFC: NAPI packet weighting patch In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0450BFE6@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0450BFE6@orsmsx408> X-Mailer: VM 7.18 under Emacs 21.4.1 X-Scanned-By: MIMEDefang 2.48 on 130.238.96.70 X-archive-position: 2038 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1102 Lines: 25 Ronciak, John writes: > > What more do you need other than checking the statistics counter? The > > drop statistics (the ones we care about) are incremented in real time > > by the ->poll() code, so it's not like we have to trigger some > > asynchronous event to get a current version of the number. > > > > I think that there is some more confusion here. I'm talking about > frames dropped by the Ethernet controller at the hardware level (no > descriptor available). This for example is happening now with our > driver with the weight set to 64. This is also what started us looking > into what was going on with the weight. I don't see how the NAPI code > to dynamically adjust the weight could easily get the hardware stats > number to know if frames are being dropped or not. Sorry if I caused > the confusion here. It's not obvious that weight is to blame for frames dropped. I would look into RX ring size in relation to HW mitigation. And of course if you system is very loaded the RX softirq gives room for other jobs and frames get dropped Cheers. --ro From john.ronciak@intel.com Fri Jun 3 11:21:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 11:21:33 -0700 (PDT) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53ILIXq011580 for ; Fri, 3 Jun 2005 11:21:21 -0700 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j53IJ3FT010376; Fri, 3 Jun 2005 18:19:03 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j53IIcdm021983; Fri, 3 Jun 2005 18:19:03 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005060311190319676 ; Fri, 03 Jun 2005 11:19:03 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Jun 2005 11:19:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC: NAPI packet weighting patch Date: Fri, 3 Jun 2005 11:19:02 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0450BFE8@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC: NAPI packet weighting patch Thread-Index: AcVoZ1hMIfRnNfjORXaqb2xRuIo6IAAAQaHw From: "Ronciak, John" To: "Robert Olsson" Cc: "David S. Miller" , , , , "Williams, Mitch A" , , "Venkatesan, Ganesh" , "Brandeburg, Jesse" X-OriginalArrivalTime: 03 Jun 2005 18:19:03.0501 (UTC) FILETIME=[B8B9F7D0:01C56868] X-Scanned-By: MIMEDefang 2.44 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j53ILIXq011580 X-archive-position: 2039 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: john.ronciak@intel.com Precedence: bulk X-list: netdev Content-Length: 584 Lines: 16 > It's not obvious that weight is to blame for frames dropped. I would > look into RX ring size in relation to HW mitigation. > And of course if you system is very loaded the RX softirq gives room > for other jobs and frames get dropped > With the same system (fairly high end with nothing major running on it) we got rid of the dropped frames by just reducing the weight for 64. So the weight did have something to do with the dropped frames. Maybe other factors as well, but in static tests like this it sure looks like the 64 value is wrong is some cases. Cheers, John From greearb@candelatech.com Fri Jun 3 11:34:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 11:34:26 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53IYEXq012436 for ; Fri, 3 Jun 2005 11:34:15 -0700 Received: from [71.112.207.80] (pool-71-112-207-80.sttlwa.dsl-w.verizon.net [71.112.207.80]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id j53J6U5I003158; Fri, 3 Jun 2005 12:06:31 -0700 Message-ID: <42A0A25C.8000503@candelatech.com> Date: Fri, 03 Jun 2005 11:33:00 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ronciak, John" CC: Robert Olsson , "David S. Miller" , jdmason@us.ibm.com, shemminger@osdl.org, hadi@cyberus.ca, "Williams, Mitch A" , netdev@oss.sgi.com, "Venkatesan, Ganesh" , "Brandeburg, Jesse" Subject: Re: RFC: NAPI packet weighting patch References: <468F3FDA28AA87429AD807992E22D07E0450BFE8@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0450BFE8@orsmsx408> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2040 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1320 Lines: 37 Ronciak, John wrote: >> It's not obvious that weight is to blame for frames dropped. I would >> look into RX ring size in relation to HW mitigation. >> And of course if you system is very loaded the RX softirq gives room >> for other jobs and frames get dropped >> > > With the same system (fairly high end with nothing major running on it) > we got rid of the dropped frames by just reducing the weight for 64. So > the weight did have something to do with the dropped frames. Maybe > other factors as well, but in static tests like this it sure looks like > the 64 value is wrong is some cases. Is this implying that having the NAPI poll do less work per poll of the driver actually increases performance? I would have guessed that the opposite would be true. Maybe the poll is disabling the IRQs on the NIC for too long, or something like that? For e1000, are you using larger than the default 256 receive descriptors? I have seen that increasing these descriptors helps decrease drops by a small percentage. Have you tried increasing the netdev-backlog setting to see if that fixes the problem (while leaving the weight at the default)? What packet sizes and speeds are you using for your tests? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From davem@davemloft.net Fri Jun 3 11:39:30 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 11:39:33 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53IdTXq013121 for ; Fri, 3 Jun 2005 11:39:29 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DeH3h-0001to-BE; Fri, 03 Jun 2005 11:38:17 -0700 Date: Fri, 03 Jun 2005 11:38:17 -0700 (PDT) Message-Id: <20050603.113817.74562842.davem@davemloft.net> To: mitch.a.williams@intel.com Cc: hadi@cyberus.ca, john.ronciak@intel.com, jdmason@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch From: "David S. Miller" In-Reply-To: References: <20050602.171812.48807872.davem@davemloft.net> <1117765954.6095.49.camel@localhost.localdomain> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2041 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1504 Lines: 33 From: Mitch Williams Date: Fri, 3 Jun 2005 10:43:32 -0700 > In my mind, there are two major problems with NAPI as it stands today. > First, at Gigabit and higher speeds, the default settings don't allow the > driver to process received packets in a timely manner. This causes > dropped packets due to lack of receive resources. Lowering the weight can > fix this, at least in a single-adapter environment. I really don't see how changing the weight can change things in the single adapter case. When we hit the quota, we just loop and process more packets. It doesn't fundamentally change anything about how the NAPI code operates. Please investigate what exactly is happening. I have a few theories. First, is it the case that with a lower weight we drop out of the loop because 'jiffies' advanced one tick? Some simply instrumentation in net/core/dev.c:net_rx_action() would show what's going on. Actually, we keep this statistic via netdev_rx_stat, so just cat /proc/net/softnet_stat to get a look at if "time_squeeze" is being incremented when dev->weight is 64 in your tests. Next, I don't think "budget" in that function is going down to zero, that's set to 300 by default. If the quota is consumed, the device is just added right back to the tail of the poll_list, and if it's the only device active we jump right back into it's ->poll() routine over and over until there is no more pending work in the device or we hit the "jiffies - start_time > 1" test. From hadi@cyberus.ca Fri Jun 3 11:44:00 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 11:44:03 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53IhxXq013815 for ; Fri, 3 Jun 2005 11:43:59 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.30) id 1DeH8M-0003zL-Lx for netdev@oss.sgi.com; Fri, 03 Jun 2005 14:43:06 -0400 Received: from [216.209.86.2] (helo=[10.0.0.229]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1DeH8J-0005ai-51; Fri, 03 Jun 2005 14:43:03 -0400 Subject: Re: RFC: NAPI packet weighting patch From: jamal Reply-To: hadi@cyberus.ca To: Mitch Williams Cc: "David S. Miller" , "Ronciak, John" , jdmason@us.ibm.com, shemminger@osdl.org, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, "Venkatesan, Ganesh" , "Brandeburg, Jesse" In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E0450BFDB@orsmsx408> <20050602.171812.48807872.davem@davemloft.net> <1117765954.6095.49.camel@localhost.localdomain> Content-Type: text/plain Organization: unknown Date: Fri, 03 Jun 2005 14:42:30 -0400 Message-Id: <1117824150.6071.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-archive-position: 2042 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 5233 Lines: 124 On Fri, 2005-03-06 at 10:43 -0700, Mitch Williams wrote: > > On Thu, 2 Jun 2005, jamal wrote: > > > > Heres what i think i saw as a flow of events: > > Someone posted a theory that if you happen to reduce the weight > > (iirc the reduction was via a shift) then the DRR would give less CPU > > time cycle to the driver - Whats the big suprise there? thats DRR design > > intent. > > Well, that was me. Or at least I was the original poster on this thread. > But my theory (if you can call it that) really wasn't about CPU time. I > spent several weeks in our lab with the somewhat nebulous task of "look at > Linux performance". And what I found was, to me, counterintuitive: > reducing weight improved performance, sometimes significantly. > When you reduce the weight, the system is spending less time in the softirq processing packets before softirq yields. If this gives more opportunity to your app to run, then the performance will go up. Is this what you are seeing? > OK, well, call me a blasphemer (against whom?). > I'm not really saying > that the DRR algorithm is not real-world, but rather that NAPI as > currently implemented has some significant performance limitations. > And we need to be fair and investigate why. > In my mind, there are two major problems with NAPI as it stands today. > First, at Gigabit and higher speeds, the default settings don't allow the > driver to process received packets in a timely manner. What do you mean by timely? > This causes > dropped packets due to lack of receive resources. Lowering the weight can > fix this, at least in a single-adapter environment. > If your know your workload you could tune the weight. Additionaly you could tune the softirq using nice. > Second, at 10Mbps and 100Mbps, modern processors are just too fast for the > network. The NAPI polling loop runs so much quicker than the wire speed > that only one or two packets are processed per softirq -- which > effectively puts the adapter back in interrupt mode. Because of this, you > can easily bog down a very fast box with relatively slow traffic, just due > to the massive number of interrupts generated. > Massive is an overstatement. The issue is really IO. If you process one packet in each interupt then NAPI does add extra IO costs at "low" traffic levels. Note that this is also a known issue - reference the threads from waay back from people like Manfred Spraul and recently from the SGI folks. IO unfortunately hasnt kept up with CPU speeds; hardware vendors such as your company have been busy making processors faster but forgetting about IO and RAM latencies. PCI-E seems promising from what i have heard, interim PCI-E bridging to PCI-X is form what i have heard on its IO performance worse. > My original post (and patch) were to address the first issue. By using > the shift value on the quota, I effectively lowered the weight for every > driver in the system. Stephen sent out a patch that allowed you to > adjust each driver's weight individually. My testing has shown that, as > expected, you can achieve the same performance gain either way. > Ok, glad to hear thats resolved. > In a multiple-adapter environment, you need to adjust the weight of all > drivers together to fix the dropped packets issue. Lowering the weight on > one adapter won't help it if the other interfaces are still taking up a > lot of time in their receive loops. > > My patch gave you one knob to twiddle that would correct this issue. > Stephen's patch gave you one knob for each adapter, but now you need to > twiddle them all to see any benefit. > makes sense > The second issue currently has no fix. What is needed is a way for the > driver to request a delayed poll, possibly based on line speed. If we > could wait, say, 8 packet times before polling, we could significantly > reduce the number of interrupts the system has to deal with, at the cost > of higher latency. We haven't had time to investigate this at all, but > the need is clearly present -- we've had customer calls about this issue. > I can believe you (note it has to do with IO costs though) having seen how horrific MMIO numbers are on faster processors. Talk to Jesse, he has seen a little program from Lennert/Robert/Harald that does MMIO measurements. It seems the trend is that as CPUs get faster, IO gets more expensive in both cpu cycles as well as absolute time. The solution to this issue is to be found in mitigation at the moment in conjunction with NAPI. The SGI folks have made some real progress with recent patches from Davem and Michael Chan on tg3. I have been experimenting with some patches but they introduce unacceptable jitter in latency. So lets summarize it this way: This is something that needs to be resolved - but whatever solution needs to be generic. > Either way, I think the netdev community needs to look critically at NAPI, > and make some changes. I think what you call as the second issue needs a solution. Mitigation is the only generic solution at the moment. > Network performance in 2.6.12-rcWhatever is > pretty poor. 2.4.30 beats it handily, and it really shouldn't be that > way. > Are you using NAPI as well on 2.4.30? cheers, jamal From davem@davemloft.net Fri Jun 3 11:51:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 11:51:07 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53Ip3Xq014729 for ; Fri, 3 Jun 2005 11:51:03 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.50) id 1DeHEs-0001vW-KJ; Fri, 03 Jun 2005 11:49:50 -0700 Date: Fri, 03 Jun 2005 11:49:50 -0700 (PDT) Message-Id: <20050603.114950.119242486.davem@davemloft.net> To: greearb@candelatech.com Cc: john.ronciak@intel.com, Robert.Olsson@data.slu.se, jdmason@us.ibm.com, shemminger@osdl.org, hadi@cyberus.ca, mitch.a.williams@intel.com, netdev@oss.sgi.com, ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com Subject: Re: RFC: NAPI packet weighting patch From: "David S. Miller" In-Reply-To: <42A0A25C.8000503@candelatech.com> References: <468F3FDA28AA87429AD807992E22D07E0450BFE8@orsmsx408> <42A0A25C.8000503@candelatech.com> X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2044 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 1080 Lines: 28 From: Ben Greear Date: Fri, 03 Jun 2005 11:33:00 -0700 > Is this implying that having the NAPI poll do less work per poll > of the driver actually increases performance? I would have guessed that > the opposite would be true. Exactly my thoughts as well :) > Maybe the poll is disabling the IRQs on the NIC for too long, or something > like that? In a reply I just sent out to this thread, I postulate that the jiffies check is hitting earlier with a lower weight value, a quick look at /proc/net/softnet_stat during their testing will confirm or deny this theory. It could also just be a simple bug in the dev->quota accounting somewhere. Note that, in all of this, I do not have any objections to providing a way to configure the dev->weight values. I will be applying Stephen Hemminger's patches. But I think we MUST find out the reason for the observed behavior, especially in the single-adapter case since the result is so illogical. We could find an important bug in the NAPI implementation, or learn something new about how NAPI behaves. From fubar@us.ibm.com Fri Jun 3 11:50:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 03 Jun 2005 11:50:15 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j53Io8Xq014546 for ; Fri, 3 Jun 2005 11:50:08 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j53In9MK501054 for ; Fri, 3 Jun 2005 14:49:09 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j53In96g177088 for ; Fri, 3 Jun 2005 12:49:09 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j53In8aT012300 for ; Fri, 3 Jun 2005 12:49:09 -0600 Received: from death.nxdomain.ibm.com (lig32-225-151-29.us.lig-dial.ibm.com [32.225.151.29]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j53Imu67011588; Fri, 3 Jun 2005 12:48:57 -0600 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id j53ImVse031367; Fri, 3 Jun 2005 11:48:51 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id j53ImAwZ031354; Fri, 3 Jun 2005 11:48:30 -0700 Message-Id: <200506031848.j53ImAwZ031354@death.nxdomain.ibm.com> To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 2.6.12-rc5] bonding: documentation update X-Mailer: MH-E 7.83; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 03 Jun 2005 11:48:09 -0700 From: Jay Vosburgh X-archive-position: 2043 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 57102 Lines: 1266 Documentation update: added some more configuration info, (hopefully) better examples, updated some out of date info, and a bonus pass through ispell to banish the "paramters." -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com Signed-off-by: Jay Vosburgh diff -ur linux-2.6.12-rc5/Documentation/networking/bonding.txt linux-doc/Documentation/networking/bonding.txt --- linux-2.6.12-rc5/Documentation/networking/bonding.txt 2005-06-03 11:29:04.394823672 -0700 +++ linux-doc/Documentation/networking/bonding.txt 2005-06-03 11:29:41.143237064 -0700 @@ -1,5 +1,7 @@ - Linux Ethernet Bonding Driver HOWTO + Linux Ethernet Bonding Driver HOWTO + + Latest update: 2 June 2005 Initial release : Thomas Davis Corrections, HA extensions : 2000/10/03-15 : @@ -11,15 +13,22 @@ Reorganized and updated Feb 2005 by Jay Vosburgh -Note : ------- +Introduction +============ + + The Linux bonding driver provides a method for aggregating +multiple network interfaces into a single logical "bonded" interface. +The behavior of the bonded interfaces depends upon the mode; generally +speaking, modes provide either hot standby or load balancing services. +Additionally, link integrity monitoring may be performed. -The bonding driver originally came from Donald Becker's beowulf patches for -kernel 2.0. It has changed quite a bit since, and the original tools from -extreme-linux and beowulf sites will not work with this version of the driver. + The bonding driver originally came from Donald Becker's +beowulf patches for kernel 2.0. It has changed quite a bit since, and +the original tools from extreme-linux and beowulf sites will not work +with this version of the driver. -For new versions of the driver, patches for older kernels and the updated -userspace tools, please follow the links at the end of this file. + For new versions of the driver, updated userspace tools, and +who to ask for help, please follow the links at the end of this file. Table of Contents ================= @@ -30,9 +39,13 @@ 3. Configuring Bonding Devices 3.1 Configuration with sysconfig support +3.1.1 Using DHCP with sysconfig +3.1.2 Configuring Multiple Bonds with sysconfig 3.2 Configuration with initscripts support +3.2.1 Using DHCP with initscripts +3.2.2 Configuring Multiple Bonds with initscripts 3.3 Configuring Bonding Manually -3.4 Configuring Multiple Bonds +3.3.1 Configuring Multiple Bonds Manually 5. Querying Bonding Configuration 5.1 Bonding Configuration @@ -56,21 +69,28 @@ 11. Promiscuous mode -12. High Availability Information +12. Configuring Bonding for High Availability 12.1 High Availability in a Single Switch Topology -12.1.1 Bonding Mode Selection for Single Switch Topology -12.1.2 Link Monitoring for Single Switch Topology 12.2 High Availability in a Multiple Switch Topology -12.2.1 Bonding Mode Selection for Multiple Switch Topology -12.2.2 Link Monitoring for Multiple Switch Topology -12.3 Switch Behavior Issues for High Availability +12.2.1 HA Bonding Mode Selection for Multiple Switch Topology +12.2.2 HA Link Monitoring for Multiple Switch Topology + +13. Configuring Bonding for Maximum Throughput +13.1 Maximum Throughput in a Single Switch Topology +13.1.1 MT Bonding Mode Selection for Single Switch Topology +13.1.2 MT Link Monitoring for Single Switch Topology +13.2 Maximum Throughput in a Multiple Switch Topology +13.2.1 MT Bonding Mode Selection for Multiple Switch Topology +13.2.2 MT Link Monitoring for Multiple Switch Topology -13. Hardware Specific Considerations -13.1 IBM BladeCenter +14. Switch Behavior Issues -14. Frequently Asked Questions +15. Hardware Specific Considerations +15.1 IBM BladeCenter -15. Resources and Links +16. Frequently Asked Questions + +17. Resources and Links 1. Bonding Driver Installation @@ -86,16 +106,10 @@ 1.1 Configure and build the kernel with bonding ----------------------------------------------- - The latest version of the bonding driver is available in the + The current version of the bonding driver is available in the drivers/net/bonding subdirectory of the most recent kernel source -(which is available on http://kernel.org). - - Prior to the 2.4.11 kernel, the bonding driver was maintained -largely outside the kernel tree; patches for some earlier kernels are -available on the bonding sourceforge site, although those patches are -still several years out of date. Most users will want to use either -the most recent kernel from kernel.org or whatever kernel came with -their distro. +(which is available on http://kernel.org). Most users "rolling their +own" will want to use the most recent kernel from kernel.org. Configure kernel with "make menuconfig" (or "make xconfig" or "make config"), then select "Bonding driver support" in the "Network @@ -103,8 +117,8 @@ driver as module since it is currently the only way to pass parameters to the driver or configure more than one bonding device. - Build and install the new kernel and modules, then proceed to -step 2. + Build and install the new kernel and modules, then continue +below to install ifenslave. 1.2 Install ifenslave Control Utility ------------------------------------- @@ -147,9 +161,9 @@ Options for the bonding driver are supplied as parameters to the bonding module at load time. They may be given as command line arguments to the insmod or modprobe command, but are usually specified -in either the /etc/modprobe.conf configuration file, or in a -distro-specific configuration file (some of which are detailed in the -next section). +in either the /etc/modules.conf or /etc/modprobe.conf configuration +file, or in a distro-specific configuration file (some of which are +detailed in the next section). The available bonding driver parameters are listed below. If a parameter is not specified the default value is used. When initially @@ -162,34 +176,34 @@ support at least miimon, so there is really no reason not to use it. Options with textual values will accept either the text name - or, for backwards compatibility, the option value. E.g., - "mode=802.3ad" and "mode=4" set the same mode. +or, for backwards compatibility, the option value. E.g., +"mode=802.3ad" and "mode=4" set the same mode. The parameters are as follows: arp_interval - Specifies the ARP monitoring frequency in milli-seconds. If - ARP monitoring is used in a load-balancing mode (mode 0 or 2), - the switch should be configured in a mode that evenly - distributes packets across all links - such as round-robin. If - the switch is configured to distribute the packets in an XOR + Specifies the ARP link monitoring frequency in milliseconds. + If ARP monitoring is used in an etherchannel compatible mode + (modes 0 and 2), the switch should be configured in a mode + that evenly distributes packets across all links. If the + switch is configured to distribute the packets in an XOR fashion, all replies from the ARP targets will be received on the same link which could cause the other team members to - fail. ARP monitoring should not be used in conjunction with - miimon. A value of 0 disables ARP monitoring. The default + fail. ARP monitoring should not be used in conjunction with + miimon. A value of 0 disables ARP monitoring. The default value is 0. arp_ip_target - Specifies the ip addresses to use when arp_interval is > 0. - These are the targets of the ARP request sent to determine the - health of the link to the targets. Specify these values in - ddd.ddd.ddd.ddd format. Multiple ip adresses must be - seperated by a comma. At least one IP address must be given - for ARP monitoring to function. The maximum number of targets - that can be specified is 16. The default value is no IP - addresses. + Specifies the IP addresses to use as ARP monitoring peers when + arp_interval is > 0. These are the targets of the ARP request + sent to determine the health of the link to the targets. + Specify these values in ddd.ddd.ddd.ddd format. Multiple IP + addresses must be separated by a comma. At least one IP + address must be given for ARP monitoring to function. The + maximum number of targets that can be specified is 16. The + default value is no IP addresses. downdelay @@ -207,11 +221,13 @@ are: slow or 0 - Request partner to transmit LACPDUs every 30 seconds (default) + Request partner to transmit LACPDUs every 30 seconds fast or 1 Request partner to transmit LACPDUs every 1 second + The default is slow. + max_bonds Specifies the number of bonding devices to create for this @@ -221,10 +237,11 @@ miimon - Specifies the frequency in milli-seconds that MII link - monitoring will occur. A value of zero disables MII link - monitoring. A value of 100 is a good starting point. The - use_carrier option, below, affects how the link state is + Specifies the MII link monitoring frequency in milliseconds. + This determines how often the link state of each slave is + inspected for link failures. A value of zero disables MII + link monitoring. A value of 100 is a good starting point. + The use_carrier option, below, affects how the link state is determined. See the High Availability section for additional information. The default value is 0. @@ -270,7 +287,7 @@ duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad specification. - Pre-requisites: + Prerequisites: 1. Ethtool support in the base drivers for retrieving the speed and duplex of each slave. @@ -333,7 +350,7 @@ When a link is reconnected or a new slave joins the bond the receive traffic is redistributed among all - active slaves in the bond by intiating ARP Replies + active slaves in the bond by initiating ARP Replies with the selected mac address to each of the clients. The updelay parameter (detailed below) must be set to a value equal or greater than the switch's @@ -448,8 +465,9 @@ slave devices. On SLES 9, this is most easily done by running the yast2 sysconfig configuration utility. The goal is for to create an ifcfg-id file for each slave device. The simplest way to accomplish -this is to configure the devices for DHCP. The name of the -configuration file for each device will be of the form: +this is to configure the devices for DHCP (this is only to get the +file ifcfg-id file created; see below for some issues with DHCP). The +name of the configuration file for each device will be of the form: ifcfg-id-xx:xx:xx:xx:xx:xx @@ -459,7 +477,7 @@ Once the set of ifcfg-id-xx:xx:xx:xx:xx:xx files has been created, it is necessary to edit the configuration files for the slave devices (the MAC addresses correspond to those of the slave devices). -Before editing, the file will contain muliple lines, and will look +Before editing, the file will contain multiple lines, and will look something like this: BOOTPROTO='dhcp' @@ -501,11 +519,6 @@ Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK values with the appropriate values for your network. - Note that configuring the bonding device with BOOTPROTO='dhcp' -does not work; the scripts attempt to obtain the device address from -DHCP prior to adding any of the slave devices. Without active slaves, -the DHCP requests are not sent to the network. - The STARTMODE specifies when the device is brought online. The possible values are: @@ -544,7 +557,7 @@ Note that the network control script (/sbin/ifdown) will remove the bonding module as part of the network shutdown processing, so it is not necessary to remove the module by hand if, e.g., the -module paramters have changed. +module parameters have changed. Also, at this writing, YaST/YaST2 will not manage bonding devices (they do not show bonding interfaces on its list of network @@ -559,12 +572,37 @@ Note that the template does not document the various BONDING_ settings described above, but does describe many of the other options. +3.1.1 Using DHCP with sysconfig +------------------------------- + + Under sysconfig, configuring a device with BOOTPROTO='dhcp' +will cause it to query DHCP for its IP address information. At this +writing, this does not function for bonding devices; the scripts +attempt to obtain the device address from DHCP prior to adding any of +the slave devices. Without active slaves, the DHCP requests are not +sent to the network. + +3.1.2 Configuring Multiple Bonds with sysconfig +----------------------------------------------- + + The sysconfig network initialization system is capable of +handling multiple bonding devices. All that is necessary is for each +bonding instance to have an appropriately configured ifcfg-bondX file +(as described above). Do not specify the "max_bonds" parameter to any +instance of bonding, as this will confuse sysconfig. If you require +multiple bonding devices with identical parameters, create multiple +ifcfg-bondX files. + + Because the sysconfig scripts supply the bonding module +options in the ifcfg-bondX file, it is not necessary to add them to +the system /etc/modules.conf or /etc/mod