Re: ES-API?
On Mon, Mar 13, 2006 at 02:25:08PM -0800, Zach Brown ([EMAIL PROTECTED]) wrote: Hi guys, Hello Zach. I'm hearing noise about the 'Extended Sockets' API in Oracle. It's an extension to the socket API put together by an industry group that calls itself the Interconnect Software Consortium and is working in partnership with the open group. The API adds support for things like memory registration, async operations completed through event queues, standard sendfile() and async poll(), etc. It's freely downloadable as a PDF from http://www.opengroup.org/icsc/doc.tpl?CALLER=index.tplgdid=6415 Page 7 has a list of contributors that seems to have a glaring lack of free unix representation of any kind :( It seems certain that the commercial Unix vendors will adopt pieces of it in some capacity. Which means Oracle guys will want to play with it. Which means I'll get questions about supporting it in Linux :) Has the netdev world developed an opinion about this stuff? There are some stuff already implemented and presented in netdev@, unfortunately it did not get much attention and feedback. Queue of events used for socket operations: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=kevent http://lwn.net/Articles/171317/ http://marc.theaimsgroup.com/?l=linux-netdevm=113949344414464w=2 Network AIO operations: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=naio sending support: http://marc.theaimsgroup.com/?l=linux-netdevm=113992502032729w=2 receiving support: http://marc.theaimsgroup.com/?l=linux-netdevm=113949344426019w=2 Sending zero-copy is supported from ... it was added very long ago. Receiving zero-copy requires special hardware, which can split protocol header from data. Some work can be found at: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=recv_zero_copy http://marc.theaimsgroup.com/?l=linux-netdevm=113465769816658w=2 So, while commercial Unix vendors create rocket-science-capable API, Linux just implements the core. - z -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] : get rid of 'struct sec_path *' in skbuff if ! CONFIG_XFRM
On Tue, Mar 14, 2006 at 07:23:05AM +0100, Eric Dumazet wrote:
Hum, but then we need a new macro or prototype, because n-sp is not valid
n-sp = secpath_get(skb-sp);
would still miscompile, even if secpath_get() is a no-op
How about just leaving sp in the structure unconditionally?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] : get rid of 'struct sec_path *' in skbuff if ! CONFIG_XFRM
Herbert Xu a écrit :
On Tue, Mar 14, 2006 at 07:23:05AM +0100, Eric Dumazet wrote:
Hum, but then we need a new macro or prototype, because n-sp is not valid
n-sp = secpath_get(skb-sp);
would still miscompile, even if secpath_get() is a no-op
How about just leaving sp in the structure unconditionally?
Cheers,
Well, the point of this patch is to shrink a little bit 'struct sk_buff' :)
In this second try, I added a secpath_copy() helper, so that CONFIG_XFRM test
is done in include/net/xfrm.h file
[PATCH] [NET] : get rid of 'struct sec_path *' in sk_buff if ! CONFIG_XFRM
There is a strange glitch about secpath_put() and secpath_get() calls.
secpath_put() is called from __kfree_skb() only if CONFIG_XFRM is defined.
secpath_get() is called from skb_clone() and copy_skb_header() if CONFIG_INET
is defined (!!!)
I think the intention was to use CONFIG_XFRM everywhere ?
If yes, we can save a 'struct sec_path' pointer from 'struct sk_buff' if !
CONFIG_XFRM
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
--- a/include/net/xfrm.h2006-03-14 08:23:19.0 +0100
+++ b/include/net/xfrm.h2006-03-14 08:26:38.0 +0100
@@ -635,6 +635,14 @@
return sp;
}
+static inline void
+secpath_copy(struct sk_buff *dst, const struct sk_buff *src)
+{
+#ifdef CONFIG_XFRM
+ dst-sp = secpath_get(src-sp);
+#endif
+}
+
extern void __secpath_destroy(struct sec_path *sp);
static inline void
--- a/include/linux/skbuff.h2006-03-13 18:30:21.0 +0100
+++ b/include/linux/skbuff.h2006-03-13 18:38:27.0 +0100
@@ -243,7 +243,9 @@
} mac;
struct dst_entry *dst;
+#ifdef CONFIG_XFRM
struct sec_path*sp;
+#endif
/*
* This is the control buffer. It is free to use for every
--- a/net/core/skbuff.c 2006-03-13 18:31:03.0 +0100
+++ b/net/core/skbuff.c 2006-03-14 08:24:33.0 +0100
@@ -415,10 +415,7 @@
C(mac);
C(dst);
dst_clone(skb-dst);
- C(sp);
-#ifdef CONFIG_INET
- secpath_get(skb-sp);
-#endif
+ secpath_copy(n, skb);
memcpy(n-cb, skb-cb, sizeof(skb-cb));
C(len);
C(data_len);
@@ -483,9 +480,7 @@
new-priority = old-priority;
new-protocol = old-protocol;
new-dst= dst_clone(old-dst);
-#ifdef CONFIG_INET
- new-sp = secpath_get(old-sp);
-#endif
+ secpath_copy(new, old);
new-h.raw = old-h.raw + offset;
new-nh.raw = old-nh.raw + offset;
new-mac.raw= old-mac.raw + offset;
Re: Router stops routing after changing MAC Address
linux-os (Dick Johnson) wrote: On Mon, 13 Mar 2006, Greg Scott wrote: Bst... Not! There are not any MAC addresses associated with any of the intercity links, usually not even in WANs! MAC is for Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC addresses. Bt. According to WikiPedia: http://en.wikipedia.org/wiki/MAC_address MAC addresses are used for: - Token ring - 802.11 wireless networks - Bluetooth - FDDI - ATM (switched virtual connections only, as part of an NSAP address) - SCSI and Fibre Channel (as part of a World Wide Name) FDDI = fiber, ATM = ATM. --Bart - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Router stops routing after changing MAC Address
Bt. According to WikiPedia: http://en.wikipedia.org/wiki/MAC_address MAC addresses are used for: - Token ring - 802.11 wireless networks - Bluetooth - FDDI - ATM (switched virtual connections only, as part of an NSAP address) - SCSI and Fibre Channel (as part of a World Wide Name) FDDI = fiber, ATM = ATM. http://developer.intel.com/design/network/products/optical/framers/ixf18104.htm It works too. Cheers, Simon -- ___ Play 100s of games for FREE! http://games.mail.com/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Router stops routing after changing MAC Address
On Tue, 14 Mar 2006, Bart Samwel wrote: linux-os (Dick Johnson) wrote: On Mon, 13 Mar 2006, Greg Scott wrote: Bst... Not! There are not any MAC addresses associated with any of the intercity links, usually not even in WANs! MAC is for Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC addresses. Bt. According to WikiPedia: http://en.wikipedia.org/wiki/MAC_address MAC addresses are used for: - Token ring - 802.11 wireless networks - Bluetooth - FDDI - ATM (switched virtual connections only, as part of an NSAP address) - SCSI and Fibre Channel (as part of a World Wide Name) FDDI = fiber, ATM = ATM. --Bart A name is NOT. I can call my mail route number RFD#2 a MAC address. Also token-ring is a form of Ethernet as are all known wireless networks unless they use light. Even cable modems use Ethernet, with FDM on the cable side and baseband on the customer side. Calling SCSI MAC is absurd. All of the above, except the ethernets are forms of point-to-point communications links. IP (over/under or through) these links uses a source and destination IP and any hardware addressing scheme is incidental. Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] hostap_{pci,plx}.c: fix memory leaks
On Monday 13 March 2006 23:28, you wrote:
This patch fixes two memotry leaks spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/wireless/hostap/hostap_pci.c |6 +++---
drivers/net/wireless/hostap/hostap_plx.c |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
--- linux-2.6.16-rc6-mm1-full/drivers/net/wireless/hostap/hostap_pci.c.old
2006-03-13 22:34:30.0 +0100
+++ linux-2.6.16-rc6-mm1-full/drivers/net/wireless/hostap/hostap_pci.c
2006-03-13 22:37:57.0 +0100
@@ -301,14 +301,14 @@ static int prism2_pci_probe(struct pci_d
struct hostap_interface *iface;
struct hostap_pci_priv *hw_priv;
+ if (pci_enable_device(pdev))
+ return -EIO;
+
hw_priv = kmalloc(sizeof(*hw_priv), GFP_KERNEL);
if (hw_priv == NULL)
+ pci_disable_device(pdev);
return -ENOMEM;
memset(hw_priv, 0, sizeof(*hw_priv));
- if (pci_enable_device(pdev))
- return -EIO;
-
phymem = pci_resource_start(pdev, 0);
if (!request_mem_region(phymem, pci_resource_len(pdev, 0), Prism2)) {
--- linux-2.6.16-rc6-mm1-full/drivers/net/wireless/hostap/hostap_plx.c.old
2006-03-13 22:39:40.0 +0100
+++ linux-2.6.16-rc6-mm1-full/drivers/net/wireless/hostap/hostap_plx.c
2006-03-13 22:40:09.0 +0100
@@ -446,14 +446,14 @@ static int prism2_plx_probe(struct pci_d
int tmd7160;
struct hostap_plx_priv *hw_priv;
+ if (pci_enable_device(pdev))
+ return -EIO;
+
hw_priv = kmalloc(sizeof(*hw_priv), GFP_KERNEL);
if (hw_priv == NULL)
Seems like pci_disable_device should be done here, too.
return -ENOMEM;
memset(hw_priv, 0, sizeof(*hw_priv));
- if (pci_enable_device(pdev))
- return -EIO;
-
/* National Datacomm NCP130 based on TMD7160, not PLX9052. */
tmd7160 = (pdev-vendor == 0x15e8) (pdev-device == 0x0131);
--
Greetings Michael.
pgpu6SRW2C7JL.pgp
Description: PGP signature
Re: Writing a Rate based transport protocol
On 3/13/06, Saurabh Jain [EMAIL PROTECTED] wrote: Hi All, I am trying to write a new rate based transport protocol in linux kernel (either as a module or directly within the kernel). Basically it would be similar to UDP but with features like dynamic rate control, connection and state management, error control like TCP. Is there any established framework which i can use? I know there is one for window based protocols like TCP where one can dynamically register different congestion control mechanisms. I would appreciate if somebody can give me some direction in this regard. Look at how DCCP and TCP share code, using abstractions such as: struct inet_connection_sock struct inet_request_sock struct inet_timewait_sock struct inet_hashinfo I suggest too that you read my OLS 2004 paper: http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf Page 305: 3 Writing a New Protocol for the Linux Kernel and page 307: 6 Linux Infrastructure for Internet Transport Protocols, but I'm a lazy boy and haven't properly finished this paper, it stops at processing connection requests, also at that time I'm not sure if I had finished the work on struct inet_hashinfo, generalising the hashtables operations for socket ID lookup, etc, look at dccp_v4_rcv and dccp_v6_rcv and you should get the idea. Also I'm more than interested in discussing ideas for further generalisation of the Linux networking infrastructure :-) - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ES-API?
On Mon, Mar 13, 2006 at 02:25:08PM -0800, Zach Brown wrote: Hi guys, I'm hearing noise about the 'Extended Sockets' API in Oracle. It's an extension to the socket API put together by an industry group that calls itself the Interconnect Software Consortium and is working in partnership with the open group. The API adds support for things like memory registration, async operations completed through event queues, standard sendfile() and async poll(), etc. It's a new bullshit standard from the crackmonkeyes at the opengroups interconnect working group that already tried to push idiocies like RNICPI onto us. I already told them that they're on crack but they don't care. It's never going to appear in Linux. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] : get rid of 'struct sec_path *' in skbuff if ! CONFIG_XFRM
On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Herbert Xu a écrit : On Tue, Mar 14, 2006 at 07:23:05AM +0100, Eric Dumazet wrote: Hum, but then we need a new macro or prototype, because n-sp is not valid n-sp = secpath_get(skb-sp); would still miscompile, even if secpath_get() is a no-op How about just leaving sp in the structure unconditionally? Cheers, Well, the point of this patch is to shrink a little bit 'struct sk_buff' :) --- a/include/linux/skbuff.h2006-03-13 18:30:21.0 +0100 +++ b/include/linux/skbuff.h2006-03-13 18:38:27.0 +0100 @@ -243,7 +243,9 @@ } mac; struct dst_entry *dst; +#ifdef CONFIG_XFRM struct sec_path*sp; +#endif Humm, we're trying to avoid/remove ifdefs in structs as most of the users will use distro kernels where most (if not all) of these config options are enabled :-\ - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Router stops routing after changing MAC Address
Yet I have real-world examples I've seen with my own eyes where MAC Address problems have messed up bridged networks. I posted some of those here yesterday. Good old Ethernet MAC Addresses can and do play a real role in these wide area networks. Don't believe me? Try it yourself. Find a LAN connected to the Internet via bridged DSL or cablemodem with a real firewall in place. Swap the firewall and wait...and wait...and wait some more for ARP caches to clear on the other end. When nothing changes but the passage of time and traffic starts to flow again - and the Internet service is bridged not routed - give me another explanation besides ARP caches. - Greg -Original Message- From: linux-os (Dick Johnson) [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 14, 2006 6:53 AM To: Bart Samwel Cc: Greg Scott; Rick Jones; Chuck Ebbert; linux-kernel; netdev@vger.kernel.org; Alan Cox; Simon Mackinlay Subject: Re: Router stops routing after changing MAC Address On Tue, 14 Mar 2006, Bart Samwel wrote: linux-os (Dick Johnson) wrote: On Mon, 13 Mar 2006, Greg Scott wrote: Bst... Not! There are not any MAC addresses associated with any of the intercity links, usually not even in WANs! MAC is for Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC addresses. Bt. According to WikiPedia: http://en.wikipedia.org/wiki/MAC_address MAC addresses are used for: - Token ring - 802.11 wireless networks - Bluetooth - FDDI - ATM (switched virtual connections only, as part of an NSAP address) - SCSI and Fibre Channel (as part of a World Wide Name) FDDI = fiber, ATM = ATM. --Bart A name is NOT. I can call my mail route number RFD#2 a MAC address. Also token-ring is a form of Ethernet as are all known wireless networks unless they use light. Even cable modems use Ethernet, with FDM on the cable side and baseband on the customer side. Calling SCSI MAC is absurd. All of the above, except the ethernets are forms of point-to-point communications links. IP (over/under or through) these links uses a source and destination IP and any hardware addressing scheme is incidental. Cheers, Dick Johnson Penguin : Linux version 2.6.15.4 on an i686 machine (5589.54 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ES-API?
Evgeniy, There are some stuff already implemented and presented in netdev@, unfortunately it did not get much attention and feedback. Queue of events used for socket operations: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=kevent http://lwn.net/Articles/171317/ http://marc.theaimsgroup.com/?l=linux-netdevm=113949344414464w=2 Network AIO operations: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=naio sending support: http://marc.theaimsgroup.com/?l=linux-netdevm=113992502032729w=2 receiving support: http://marc.theaimsgroup.com/?l=linux-netdevm=113949344426019w=2 Sending zero-copy is supported from ... it was added very long ago. Receiving zero-copy requires special hardware, which can split protocol header from data. Some work can be found at: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=recv_zero_copy http://marc.theaimsgroup.com/?l=linux-netdevm=113465769816658w=2 So, while commercial Unix vendors create rocket-science-capable API, Linux just implements the core. Your patches have been recently discussed on ACE mail list (ACE is an Adaptive Communication Environment - a userspace framework toolkit for OO communication) regarding future support of linux kernel to so-called Proactor design pattern, where true asynch support from kernel has real advantages. -- Sincerely, --- Robert Iakobashvili, coroberti at gmail dot com NAVIGARE NECESSE EST -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ES-API?
On Tue, Mar 14, 2006 at 05:48:41PM +0200, Robert Iakobashvili ([EMAIL PROTECTED]) wrote: Evgeniy, There are some stuff already implemented and presented in netdev@, unfortunately it did not get much attention and feedback. Queue of events used for socket operations: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=kevent http://lwn.net/Articles/171317/ http://marc.theaimsgroup.com/?l=linux-netdevm=113949344414464w=2 Network AIO operations: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=naio sending support: http://marc.theaimsgroup.com/?l=linux-netdevm=113992502032729w=2 receiving support: http://marc.theaimsgroup.com/?l=linux-netdevm=113949344426019w=2 Sending zero-copy is supported from ... it was added very long ago. Receiving zero-copy requires special hardware, which can split protocol header from data. Some work can be found at: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=recv_zero_copy http://marc.theaimsgroup.com/?l=linux-netdevm=113465769816658w=2 So, while commercial Unix vendors create rocket-science-capable API, Linux just implements the core. Your patches have been recently discussed on ACE mail list (ACE is an Adaptive Communication Environment - a userspace framework toolkit for OO communication) regarding future support of linux kernel to so-called Proactor design pattern, where true asynch support from kernel has real advantages. Ugh... So people can find the ways to connect kernelspace event queue and asynchronous networking operations with object-oriented design patterns? It's time to me to have a step forward from stone age... Could you please provide a link, it would be nice to read this discussion. -- Sincerely, --- Robert Iakobashvili, coroberti at gmail dot com NAVIGARE NECESSE EST -- -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Fwd: Re: [PATCH 15/16] ipw2200: switch to the new ipw2200-fw-3.0 image format]
Sam Leffler wrote: I don't see how to verify the image being loaded is appropriate for the operating mode. The old fw header had a mode field (0 bss, 1 ibss, 2 monitor) but the new one does not--unless it's encoded in the version field? The filename alone indicates the mode with the new images. James - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] : get rid of 'struct sec_path *' in skbuff if ! CONFIG_XFRM
Arnaldo Carvalho de Melo a écrit : On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Herbert Xu a écrit : On Tue, Mar 14, 2006 at 07:23:05AM +0100, Eric Dumazet wrote: Hum, but then we need a new macro or prototype, because n-sp is not valid n-sp = secpath_get(skb-sp); would still miscompile, even if secpath_get() is a no-op How about just leaving sp in the structure unconditionally? Cheers, Well, the point of this patch is to shrink a little bit 'struct sk_buff' :) --- a/include/linux/skbuff.h2006-03-13 18:30:21.0 +0100 +++ b/include/linux/skbuff.h2006-03-13 18:38:27.0 +0100 @@ -243,7 +243,9 @@ } mac; struct dst_entry *dst; +#ifdef CONFIG_XFRM struct sec_path*sp; +#endif Humm, we're trying to avoid/remove ifdefs in structs as most of the users will use distro kernels where most (if not all) of these config options are enabled :-\ Sure, but in the case of distro kernel, as you said, CONFIG_XFRM will be defined. My patch changes nothing for them. Should we delete all #ifdef CONFIG_ from linux kernel sources because of distros ? At least for us developers, the #ifdef permits to detect some code that would try to access sp, while secpath_put() is not called (so a memory leak happens) If we really want to bloat kernel structures, then we *should* change __kfree_skb() and really call secpath_put() (delete the #ifdef CONFIG_XFRM) spinlock_t for example are (null)/(void) on UP kernels (!CONFIG_SMP) , should I define a special sec_path_ref_t type that happens to be a (null)/(void) if !CONFIG_XFRM ? Defining a type for one occurrence (in struct sk_buf) seems overkill, and Linus would kill us for that. Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ES-API?
See the links below. On 3/14/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: So, while commercial Unix vendors create rocket-science-capable API, Linux just implements the core. Your patches have been recently discussed on ACE mail list regarding future support of linux kernel to so-called Proactor design pattern, where true asynch support from kernel has real advantages. So people can find the ways to connect kernelspace event queue and asynchronous networking operations with object-oriented design patterns? It's time to me to have a step forward from stone age... Could you please provide a link, it would be nice to read this discussion. For the discussion, see http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/51c815d5868a5c4a/82bd450ef8f42593?q=Proactor+linux+kernelrnum=1#82bd450ef8f42593 For other Proactor discussions: http://groups.google.com/group/comp.soft-sys.ace/search?q=Proactor+linux+kernelstart=0scoring=d; For the Proactor pattern: http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf and other files in http://www.cs.wustl.edu/~schmidt/PDF Enjoy, -- Sincerely, --- Robert Iakobashvili, coroberti at gmail dot com NAVIGARE NECESSE EST -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole: no IP address for eth0, aborting
On Sun, Mar 12, 2006 at 04:27:51PM -0800, Randy.Dunlap wrote: hardware: e1000 NIC in ThinkPad T42 kernel: 2.6.16-rc5-mm3 I always get $subject message. I changed the delay in net/core/netpoll.c from 4 seconds to 9 seconds, but it doesn't matter, the e1000 always finds Link is Up immediately after $subject message. I suppose this is a consequence of e1000 using a workqueue for some of its init code. Maybe it would work better on an MP machine instead of UP (giving e1000 a CPU to init on?). I guess I'll have to switch from netconsole built-in to use a loadable module instead. That could work for some non-kernel-init debugging, but this really needs to work for kernel init-time debugging as well IMO. That's an odd message. Are you specifying an IP address on the command line? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ES-API?
Ugh... So people can find the ways to connect kernelspace event queue and asynchronous networking operations with object-oriented design patterns? It's time to me to have a step forward from stone age... yep ;-). Could you please provide a link, it would be nice to read this discussion. Here is a link to a paper describing the patern http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf You may also be interested to know that boost ( http:/www.boost.org ) has been reviewing a C++ library submission that simulates async I/O through the use of user space threads. Discussion thread on boost is ASIO. /ikh This email has been scanned for all viruses by the MessageLabs SkyScan service. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole: no IP address for eth0, aborting
On Mon, 13 Mar 2006 22:29:12 -0600 Matt Mackall wrote: On Sun, Mar 12, 2006 at 04:27:51PM -0800, Randy.Dunlap wrote: hardware: e1000 NIC in ThinkPad T42 kernel: 2.6.16-rc5-mm3 I always get $subject message. I changed the delay in net/core/netpoll.c from 4 seconds to 9 seconds, but it doesn't matter, the e1000 always finds Link is Up immediately after $subject message. I suppose this is a consequence of e1000 using a workqueue for some of its init code. Maybe it would work better on an MP machine instead of UP (giving e1000 a CPU to init on?). I guess I'll have to switch from netconsole built-in to use a loadable module instead. That could work for some non-kernel-init debugging, but this really needs to work for kernel init-time debugging as well IMO. That's an odd message. Are you specifying an IP address on the command line? Yes, I am specifying a target IP address and a target MAC address. Is that OK or should I not specify the IP address? --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] : get rid of 'struct sec_path *' in skbuff if ! CONFIG_XFRM
On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Arnaldo Carvalho de Melo a écrit : On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Herbert Xu a écrit : On Tue, Mar 14, 2006 at 07:23:05AM +0100, Eric Dumazet wrote: Hum, but then we need a new macro or prototype, because n-sp is not valid n-sp = secpath_get(skb-sp); would still miscompile, even if secpath_get() is a no-op How about just leaving sp in the structure unconditionally? Cheers, Well, the point of this patch is to shrink a little bit 'struct sk_buff' :) --- a/include/linux/skbuff.h2006-03-13 18:30:21.0 +0100 +++ b/include/linux/skbuff.h2006-03-13 18:38:27.0 +0100 @@ -243,7 +243,9 @@ } mac; struct dst_entry *dst; +#ifdef CONFIG_XFRM struct sec_path*sp; +#endif Humm, we're trying to avoid/remove ifdefs in structs as most of the users will use distro kernels where most (if not all) of these config options are enabled :-\ Sure, but in the case of distro kernel, as you said, CONFIG_XFRM will be defined. My patch changes nothing for them. Should we delete all #ifdef CONFIG_ from linux kernel sources because of distros ? At least for us developers, the #ifdef permits to detect some code that would try to access sp, while secpath_put() is not called (so a memory leak happens) If we really want to bloat kernel structures, then we *should* change __kfree_skb() and really call secpath_put() (delete the #ifdef CONFIG_XFRM) spinlock_t for example are (null)/(void) on UP kernels (!CONFIG_SMP) , should I define a special sec_path_ref_t type that happens to be a (null)/(void) if !CONFIG_XFRM ? Defining a type for one occurrence (in struct sk_buf) seems overkill, and Linus would kill us for that. handwaving mode=perhaps_silly Humm, I was thinking more about something similar to the struct sock hierarchy, where we use different slabcaches for different purposes, extending a basic sk_buff and switching the slabcache used for sk_buffs when using things that requires specific non-basic sk_buff fields, but I'd have to come up with patches to see if this is not mode=perhaps_silly 8) /handwaving - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] : get rid of 'struct sec_path *' in skbuff if ! CONFIG_XFRM
Arnaldo Carvalho de Melo a écrit : On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Arnaldo Carvalho de Melo a écrit : On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Herbert Xu a écrit : On Tue, Mar 14, 2006 at 07:23:05AM +0100, Eric Dumazet wrote: Hum, but then we need a new macro or prototype, because n-sp is not valid n-sp = secpath_get(skb-sp); would still miscompile, even if secpath_get() is a no-op How about just leaving sp in the structure unconditionally? Cheers, Well, the point of this patch is to shrink a little bit 'struct sk_buff' :) --- a/include/linux/skbuff.h2006-03-13 18:30:21.0 +0100 +++ b/include/linux/skbuff.h2006-03-13 18:38:27.0 +0100 @@ -243,7 +243,9 @@ } mac; struct dst_entry *dst; +#ifdef CONFIG_XFRM struct sec_path*sp; +#endif Humm, we're trying to avoid/remove ifdefs in structs as most of the users will use distro kernels where most (if not all) of these config options are enabled :-\ Sure, but in the case of distro kernel, as you said, CONFIG_XFRM will be defined. My patch changes nothing for them. Should we delete all #ifdef CONFIG_ from linux kernel sources because of distros ? At least for us developers, the #ifdef permits to detect some code that would try to access sp, while secpath_put() is not called (so a memory leak happens) If we really want to bloat kernel structures, then we *should* change __kfree_skb() and really call secpath_put() (delete the #ifdef CONFIG_XFRM) spinlock_t for example are (null)/(void) on UP kernels (!CONFIG_SMP) , should I define a special sec_path_ref_t type that happens to be a (null)/(void) if !CONFIG_XFRM ? Defining a type for one occurrence (in struct sk_buf) seems overkill, and Linus would kill us for that. handwaving mode=perhaps_silly Humm, I was thinking more about something similar to the struct sock hierarchy, where we use different slabcaches for different purposes, extending a basic sk_buff and switching the slabcache used for sk_buffs when using things that requires specific non-basic sk_buff fields, but I'd have to come up with patches to see if this is not mode=perhaps_silly 8) /handwaving Thats an idea (David already mentioned it), but only for simple hierarchy (2 levels at most) Let's take an example : struct file definition from 'include/linux/fs.h' Many fields are seldom used (for sockets) : unsigned intf_uid, f_gid; /* only by an obscure netfilter thing */ struct file_ra_statef_ra; /* only for readahead capable files (regular files) */ struct list_headf_ep_links; /* ony if epoll is used */ spinlock_t f_ep_lock; void*f_security; /* only if strong security */ struct fown_struct f_owner; /* ... */ The 'f_ra' is so big it would really be a win to include it only for readahead capable files... I had a patch to address this problem. Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/net/chelsio/sge.c: two array overflows
I had meant to say the array contains 3 elements but should only access index 2. Sorry for the confusion. -Scott Ingo Oeser wrote: Hi Scott, You wrote: This is a bug. The array should contain 2 elements. Sure? It either contains 3 elements or your patch is not fixing the issue. Please comment on the list which one is wrong :-) Remember that array indexes start with 0 in C: int ary[3]; ary[0] = 1; ary[1] = 2; ary[2] = 3; Regards Ingo Oeser - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] : get rid of 'struct sec_path *' in skbuff if ! CONFIG_XFRM
On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Arnaldo Carvalho de Melo a écrit : On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Arnaldo Carvalho de Melo a écrit : On 3/14/06, Eric Dumazet [EMAIL PROTECTED] wrote: Herbert Xu a écrit : On Tue, Mar 14, 2006 at 07:23:05AM +0100, Eric Dumazet wrote: Hum, but then we need a new macro or prototype, because n-sp is not valid n-sp = secpath_get(skb-sp); would still miscompile, even if secpath_get() is a no-op How about just leaving sp in the structure unconditionally? Cheers, Well, the point of this patch is to shrink a little bit 'struct sk_buff' :) --- a/include/linux/skbuff.h2006-03-13 18:30:21.0 +0100 +++ b/include/linux/skbuff.h2006-03-13 18:38:27.0 +0100 @@ -243,7 +243,9 @@ } mac; struct dst_entry *dst; +#ifdef CONFIG_XFRM struct sec_path*sp; +#endif Humm, we're trying to avoid/remove ifdefs in structs as most of the users will use distro kernels where most (if not all) of these config options are enabled :-\ Sure, but in the case of distro kernel, as you said, CONFIG_XFRM will be defined. My patch changes nothing for them. Should we delete all #ifdef CONFIG_ from linux kernel sources because of distros ? At least for us developers, the #ifdef permits to detect some code that would try to access sp, while secpath_put() is not called (so a memory leak happens) If we really want to bloat kernel structures, then we *should* change __kfree_skb() and really call secpath_put() (delete the #ifdef CONFIG_XFRM) spinlock_t for example are (null)/(void) on UP kernels (!CONFIG_SMP) , should I define a special sec_path_ref_t type that happens to be a (null)/(void) if !CONFIG_XFRM ? Defining a type for one occurrence (in struct sk_buf) seems overkill, and Linus would kill us for that. handwaving mode=perhaps_silly Humm, I was thinking more about something similar to the struct sock hierarchy, where we use different slabcaches for different purposes, extending a basic sk_buff and switching the slabcache used for sk_buffs when using things that requires specific non-basic sk_buff fields, but I'd have to come up with patches to see if this is not mode=perhaps_silly 8) /handwaving Thats an idea (David already mentioned it), but only for simple hierarchy (2 levels at most) I guess it was me that mentioned this in the past, but anyway, idea involves something like skb_alloc_private_area() done at module initialization time, where we'd get just an offset into the extension part of a sk_buff, code would use something like skb_has_private_area(id) or something like that to verify if the skb instance was suitable for its purposes, anyway, just more handwaving 8) - Arnaldo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] forcedeth: move config to gigabit menu
Since the nforce ether ethernet driver supports gigabit, it should be moved down in the Kconfig file to show up in the 1000Mbit submenu. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- test-2.6/drivers/net/Kconfig.orig 2006-03-14 10:45:13.0 -0800 +++ test-2.6/drivers/net/Kconfig2006-03-14 10:46:31.0 -0800 @@ -1371,19 +1371,6 @@ file:Documentation/networking/net-modules.txt. The module will be called b44. -config FORCEDETH - tristate Reverse Engineered nForce Ethernet support (EXPERIMENTAL) - depends on NET_PCI PCI EXPERIMENTAL - help - If you have a network (Ethernet) controller of this type, say Y and - read the Ethernet-HOWTO, available from - http://www.tldp.org/docs.html#howto. - - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module will be - called forcedeth. - - config CS89x0 tristate CS89x0 support depends on NET_PCI (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 || ARCH_PNX010X) @@ -2221,6 +2208,19 @@ This enables support for Port 2 of the Marvell MV643XX Gigabit Ethernet. +config FORCEDETH + tristate Reverse Engineered nForce Ethernet support (EXPERIMENTAL) + depends on NET_PCI PCI EXPERIMENTAL + help + If you have a network (Ethernet) controller of this type, say Y and + read the Ethernet-HOWTO, available from + http://www.tldp.org/docs.html#howto. + + To compile this driver as a module, choose M here and read + file:Documentation/networking/net-modules.txt. The module will be + called forcedeth. + + endmenu # - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netconsole: no IP address for eth0, aborting
On Tue, Mar 14, 2006 at 09:31:08AM -0800, Randy.Dunlap wrote: On Mon, 13 Mar 2006 22:29:12 -0600 Matt Mackall wrote: On Sun, Mar 12, 2006 at 04:27:51PM -0800, Randy.Dunlap wrote: hardware: e1000 NIC in ThinkPad T42 kernel: 2.6.16-rc5-mm3 I always get $subject message. I changed the delay in net/core/netpoll.c from 4 seconds to 9 seconds, but it doesn't matter, the e1000 always finds Link is Up immediately after $subject message. I suppose this is a consequence of e1000 using a workqueue for some of its init code. Maybe it would work better on an MP machine instead of UP (giving e1000 a CPU to init on?). I guess I'll have to switch from netconsole built-in to use a loadable module instead. That could work for some non-kernel-init debugging, but this really needs to work for kernel init-time debugging as well IMO. That's an odd message. Are you specifying an IP address on the command line? Yes, I am specifying a target IP address and a target MAC address. Is that OK or should I not specify the IP address? That's fine, but you also need to specify a _source_ IP address. If the interface is up and configured, we can use its IP address, but that obviously doesn't work at boot time. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] forcedeth: move config to gigabit menu
Can we remove Reverse Engineered and (EXPERIMENTAL) now? Thanks, Ayaz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Hemminger Sent: Tuesday, March 14, 2006 10:50 AM To: Manfred Spraul [EMAIL PROTECTED], Jeff Garzik [EMAIL PROTECTED]@osdl.org Cc: netdev@vger.kernel.org Subject: [PATCH] forcedeth: move config to gigabit menu Since the nforce ether ethernet driver supports gigabit, it should be moved down in the Kconfig file to show up in the 1000Mbit submenu. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- test-2.6/drivers/net/Kconfig.orig 2006-03-14 10:45:13.0 -0800 +++ test-2.6/drivers/net/Kconfig2006-03-14 10:46:31.0 -0800 @@ -1371,19 +1371,6 @@ file:Documentation/networking/net-modules.txt. The module will be called b44. -config FORCEDETH - tristate Reverse Engineered nForce Ethernet support (EXPERIMENTAL) - depends on NET_PCI PCI EXPERIMENTAL - help - If you have a network (Ethernet) controller of this type, say Y and - read the Ethernet-HOWTO, available from - http://www.tldp.org/docs.html#howto. - - To compile this driver as a module, choose M here and read - file:Documentation/networking/net-modules.txt. The module will be - called forcedeth. - - config CS89x0 tristate CS89x0 support depends on NET_PCI (ISA || MACH_IXDP2351 || ARCH_IXDP2X01 || ARCH_PNX010X) @@ -2221,6 +2208,19 @@ This enables support for Port 2 of the Marvell MV643XX Gigabit Ethernet. +config FORCEDETH + tristate Reverse Engineered nForce Ethernet support (EXPERIMENTAL) + depends on NET_PCI PCI EXPERIMENTAL + help + If you have a network (Ethernet) controller of this type, say Y and + read the Ethernet-HOWTO, available from + http://www.tldp.org/docs.html#howto. + + To compile this driver as a module, choose M here and read + file:Documentation/networking/net-modules.txt. The module will be + called forcedeth. + + endmenu # - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ethtool] UFO patch
Hi,
Kernel version 2.6.15 onwards provides UDP Fragmentation Offload (UFO)
This patch to ethtool provides UFO (UDP Fragmentation Offload) on/off support
using -K option similar to feature TSO.
To find out whether UFO is enabled or not use
#ethtool -k eth3
Offload parameters for eth3:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: on
#
To turn off UFO use following command.
#ethtool -K eth3 ufo off
To turn off UFO use following command.
#ethtool -K eth3 ufo on
Please review the patch.
Signed-off-by: Ananda Raju [EMAIL PROTECTED]
---
diff -uNr ethtool/ethtool-copy.h ethtool_ufo/ethtool-copy.h
--- ethtool/ethtool-copy.h 2006-03-14 02:33:38.0 -0800
+++ ethtool_ufo/ethtool-copy.h 2006-03-14 02:24:13.0 -0800
@@ -283,6 +283,8 @@
#define ETHTOOL_GSTATS 0x001d /* get NIC-specific statistics */
#define ETHTOOL_GTSO 0x001e /* Get TSO enable (ethtool_value) */
#define ETHTOOL_STSO 0x001f /* Set TSO enable (ethtool_value) */
+#define ETHTOOL_GUFO 0x0021 /* Get UFO enable (ethtool_value) */
+#define ETHTOOL_SUFO 0x0022 /* Set UFO enable (ethtool_value) */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff -uNr ethtool/ethtool.8 ethtool_ufo/ethtool.8
--- ethtool/ethtool.8 2006-03-14 02:33:38.0 -0800
+++ ethtool_ufo/ethtool.8 2006-03-14 02:34:54.0 -0800
@@ -153,6 +153,7 @@
.B2 tx on off
.B2 sg on off
.B2 tso on off
+.B2 ufo on off
.B ethtool \-p|\-\-blink
.I ethX
@@ -272,6 +273,9 @@
.A2 tso on off
Specify if tcp segmentation offload is enabled.
.TP
+.A2 ufo on off
+Specify if UDP fragmentation offload is enabled
+.TP
.B \-p \-\-identify
initiates adapter-specific action intended to enable an operator to
easily identify the adapter by sight. Typically this involves
diff -uNr ethtool/ethtool.c ethtool_ufo/ethtool.c
--- ethtool/ethtool.c 2006-03-14 02:33:38.0 -0800
+++ ethtool_ufo/ethtool.c 2006-03-14 02:24:07.0 -0800
@@ -144,7 +144,8 @@
[ rx on|off ]\n
[ tx on|off ]\n
[ sg on|off ]\n
- [ tso on|off ]\n },
+ [ tso on|off ]\n
+ [ ufo on|off ]\n },
{ -i, --driver, MODE_GDRV, Show driver information },
{ -d, --register-dump, MODE_GREGS, Do a register dump },
{ -e, --eeprom-dump, MODE_GEEPROM, Do a EEPROM dump,
@@ -189,6 +190,7 @@
static int off_csum_tx_wanted = -1;
static int off_sg_wanted = -1;
static int off_tso_wanted = -1;
+static int off_ufo_wanted = -1;
static struct ethtool_pauseparam epause;
static int gpause_changed = 0;
@@ -292,6 +294,7 @@
{ tx, CMDL_BOOL, off_csum_tx_wanted, NULL },
{ sg, CMDL_BOOL, off_sg_wanted, NULL },
{ tso, CMDL_BOOL, off_tso_wanted, NULL },
+ { ufo, CMDL_BOOL, off_ufo_wanted, NULL },
};
static struct cmdline_info cmdline_pause[] = {
@@ -1112,17 +1115,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 ufo)
{
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 fragmentation offload: %s\n,
rx ? on : off,
tx ? on : off,
sg ? on : off,
- tso ? on : off);
+ tso ? on : off,
+ ufo ? on : off);
return 0;
}
@@ -1386,7 +1391,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, ufo = 0;
fprintf(stdout, Offload parameters for %s:\n, devname);
@@ -1430,12 +1435,22 @@
allfail = 0;
}
+ eval.cmd = ETHTOOL_GUFO;
+ ifr-ifr_data = (caddr_t)eval;
+ err = ioctl(fd, SIOCETHTOOL, ifr);
+ if (err)
+ perror(Cannot get device udp large send offload settings);
+ else {
+ ufo = 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, ufo);
}
static int do_soffload(int fd, struct ifreq *ifr)
@@ -1490,6 +1505,17 @@
return 88;
}
}
+ if (off_ufo_wanted = 0) {
+ changed = 1;
+ eval.cmd = ETHTOOL_SUFO;
+ eval.data = (off_ufo_wanted == 1);
+ ifr-ifr_data =
Re: [PATCH 1/8] [I/OAT] DMA memcpy subsystem
Hi! --- /dev/null +++ b/drivers/dma/dmaengine.c @@ -0,0 +1,360 @@ +/* +Copyright(c) 2004 - 2006 Intel Corporation. All rights reserved. + +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. + +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. + +The full GNU General Public License is included in this distribution in the +file called LICENSE. +*/ Could you use /* * */ comment style, and describe in one or two lines what the source does in the header? Pavel -- 209:using System.IO; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Router stops routing after changing MAC Address
On Mon, 13 Mar 2006 17:35:50 EST, linux-os (Dick Johnson) said: Bst... Not! There are not any MAC addresses associated with any of the intercity links, usually not even in WANs! MAC is for Ethernet! Once you go to fiber, ATM, T-N, etc., there are no MAC addresses. This will come as a big surprise to those places running Gig-E and 10G-E links into a fiber for long-haul cross-country connectivity. pgpO89beRHvTt.pgp Description: PGP signature
[PATCH 2.6.16-rc6 1/3] e100/e1000/ixgb: update MAINTAINERS to current developers
From: Jesse Brandeburg [EMAIL PROTECTED] Remove Ganesh, add Jeff and Jesse Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] --- MAINTAINERS | 16 ++-- 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3d7d30d..1c67d8c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1349,10 +1349,10 @@ S: Maintained INTEL PRO/100 ETHERNET SUPPORT P: John Ronciak M: [EMAIL PROTECTED] -P: Ganesh Venkatesan -M: [EMAIL PROTECTED] P: Jesse Brandeburg M: [EMAIL PROTECTED] +P: Jeff Kirsher +M: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ S: Supported @@ -1361,18 +1361,22 @@ P: Jeb Cramer M: [EMAIL PROTECTED] P: John Ronciak M: [EMAIL PROTECTED] -P: Ganesh Venkatesan -M: [EMAIL PROTECTED] +P: Jesse Brandeburg +M: [EMAIL PROTECTED] +P: Jeff Kirsher +M: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ S: Supported INTEL PRO/10GbE SUPPORT +P: Jeff Kirsher +M: [EMAIL PROTECTED] P: Ayyappan Veeraiyan M: [EMAIL PROTECTED] -P: Ganesh Venkatesan -M: [EMAIL PROTECTED] P: John Ronciak M: [EMAIL PROTECTED] +P: Jesse Brandeburg +M: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ S: Supported - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.16-rc6 0/3] MAINTAINERS, e100 and e1000 text file updates
okay, here goes... these patches are against Linus's current tree. They only update text files, no code updates. The large change to e1000.txt includes whitespace changes, and some content. They could be included with 2.6.16 as they are for the drivers that are already merged. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] --- The following changes since commit a488edc914aa1d766a4e2c982b5ae03d5657ec1b: are found in the git repository at: git://198.78.49.142/~jbrandeb/linux-2.6 e1000-fixes Jesse Brandeburg: e100/e1000/ixgb: update MAINTAINERS to current developers e100: update e100.txt e1000: update the readme with the latest text Documentation/networking/e100.txt | 158 +--- Documentation/networking/e1000.txt | 710 MAINTAINERS| 16 + 3 files changed, 586 insertions(+), 298 deletions(-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.16-rc6 2/3] e100: update e100.txt
From: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
---
Documentation/networking/e100.txt | 158 +++--
1 files changed, 97 insertions(+), 61 deletions(-)
diff --git a/Documentation/networking/e100.txt
b/Documentation/networking/e100.txt
index 4ef9f7c..944aa55 100644
--- a/Documentation/networking/e100.txt
+++ b/Documentation/networking/e100.txt
@@ -1,16 +1,17 @@
Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
==
-November 17, 2004
-
+November 15, 2005
Contents
- In This Release
- Identifying Your Adapter
+- Building and Installation
- Driver Configuration Parameters
- Additional Configurations
+- Known Issues
- Support
@@ -18,18 +19,30 @@ In This Release
===
This file describes the Linux* Base Driver for the Intel(R) PRO/100 Family of
-Adapters, version 3.3.x. This driver supports 2.4.x and 2.6.x kernels.
+Adapters. This driver includes support for Itanium(R)2-based systems.
+
+For questions related to hardware requirements, refer to the documentation
+supplied with your Intel PRO/100 adapter.
+
+The following features are now available in supported kernels:
+ - Native VLANs
+ - Channel Bonding (teaming)
+ - SNMP
+
+Channel Bonding documentation can be found in the Linux kernel source:
+/Documentation/networking/bonding.txt
+
Identifying Your Adapter
-For more information on how to identify your adapter, go to the Adapter
+For more information on how to identify your adapter, go to the Adapter
Driver ID Guide at:
http://support.intel.com/support/network/adapter/pro100/21397.htm
-For the latest Intel network drivers for Linux, refer to the following
-website. In the search field, enter your adapter name or type, or use the
+For the latest Intel network drivers for Linux, refer to the following
+website. In the search field, enter your adapter name or type, or use the
networking link on the left to search for your adapter:
http://downloadfinder.intel.com/scripts-df/support_intel.asp
@@ -40,73 +53,75 @@ Driver Configuration Parameters
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
-Rx Descriptors: Number of receive descriptors. A receive descriptor is a data
- structure that describes a receive buffer and its attributes to the network
- controller. The data in the descriptor is used by the controller to write
- data from the controller to host memory. In the 3.0.x driver the valid
- range for this parameter is 64-256. The default value is 64. This parameter
- can be changed using the command
-
+Rx Descriptors: Number of receive descriptors. A receive descriptor is a data
+ structure that describes a receive buffer and its attributes to the network
+ controller. The data in the descriptor is used by the controller to write
+ data from the controller to host memory. In the 3.x.x driver the valid range
+ for this parameter is 64-256. The default value is 64. This parameter can be
+ changed using the command:
+
ethtool -G eth? rx n, where n is the number of desired rx descriptors.
-Tx Descriptors: Number of transmit descriptors. A transmit descriptor is a
- data structure that describes a transmit buffer and its attributes to the
- network controller. The data in the descriptor is used by the controller to
- read data from the host memory to the controller. In the 3.0.x driver the
- valid range for this parameter is 64-256. The default value is 64. This
- parameter can be changed using the command
+Tx Descriptors: Number of transmit descriptors. A transmit descriptor is a data
+ structure that describes a transmit buffer and its attributes to the network
+ controller. The data in the descriptor is used by the controller to read
+ data from the host memory to the controller. In the 3.x.x driver the valid
+ range for this parameter is 64-256. The default value is 64. This parameter
+ can be changed using the command:
ethtool -G eth? tx n, where n is the number of desired tx descriptors.
-Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by
- default. Ethtool can be used as follows to force speed/duplex.
+Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by
+ default. Ethtool can be used as follows to force speed/duplex.
ethtool -s eth? autoneg off speed {10|100} duplex {full|half}
NOTE: setting the speed/duplex to incorrect values will cause the link to
fail.
-Event Log Message Level: The driver uses the message level flag to log events
- to syslog. The message level can be set at driver load time. It can also be
- set using the command
+Event Log Message Level: The driver uses the message level flag to log events
+ to syslog. The message level can be set at driver
[PATCH 2.6.16-rc6 3/3] e1000: update the readme with the latest text
From: Jesse Brandeburg [EMAIL PROTECTED] The text of the e1000.txt file is a little stale, lets freshen it up. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] --- Documentation/networking/e1000.txt | 710 1 files changed, 479 insertions(+), 231 deletions(-) diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 2ebd405..221b9ca 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt @@ -1,7 +1,7 @@ Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters === -November 17, 2004 +November 15, 2005 Contents @@ -9,6 +9,7 @@ Contents - In This Release - Identifying Your Adapter +- Building and Installation - Command Line Parameters - Speed and Duplex Configuration - Additional Configurations @@ -20,254 +21,377 @@ In This Release === This file describes the Linux* Base Driver for the Intel(R) PRO/1000 Family -of Adapters, version 5.x.x. +of Adapters. This driver supports kernel versions 2.4.x and 2.6.x. This +driver includes support for Itanium(R)2-based systems. -For questions related to hardware requirements, refer to the documentation -supplied with your Intel PRO/1000 adapter. All hardware requirements listed -apply to use with Linux. +This driver is only supported as a loadable module at this time. Intel is +not supplying patches against the kernel source to allow for static linking +of the driver. For questions related to hardware requirements, refer to the +documentation supplied with your Intel PRO/1000 adapter. All hardware +requirements listed apply to use with Linux. + +The following features are now available in supported kernels: + - Native VLANs + - Channel Bonding (teaming) + - SNMP + +Channel Bonding documentation can be found in the Linux kernel source: +/Documentation/networking/bonding.txt + +The driver information previously displayed in the /proc filesystem is not +supported in this release. Alternatively, you can use ethtool (version 1.6 +or later), lspci, and ifconfig to obtain the same information. + +Instructions on updating ethtool can be found in the section Additional +Configurations later in this document. -Native VLANs are now available with supported kernels. Identifying Your Adapter -For more information on how to identify your adapter, go to the Adapter +For more information on how to identify your adapter, go to the Adapter Driver ID Guide at: http://support.intel.com/support/network/adapter/pro100/21397.htm -For the latest Intel network drivers for Linux, refer to the following -website. In the search field, enter your adapter name or type, or use the +For the latest Intel network drivers for Linux, refer to the following +website. In the search field, enter your adapter name or type, or use the networking link on the left to search for your adapter: http://downloadfinder.intel.com/scripts-df/support_intel.asp + +Building and Installation += + +To build a binary RPM* package of this driver, run 'rpmbuild -tb +filename.tar.gz'. Replace filename.tar.gz with the specific filename +of the driver. + +NOTE: For the build to work properly, the currently running kernel MUST + match the version and configuration of the installed kernel sources. + If you have just recompiled the kernel reboot the system now. + + RPM functionality has only been tested in Red Hat distributions. + +1. Move the base driver tar file to the directory of your choice. For + example, use /home/username/e1000 or /usr/local/src/e1000. + +2. Untar/unzip archive: + + tar zxf e1000-x.x.x.tar.gz + +3. Change to the driver src directory: + + cd e1000-x.x.x/src/ + +4. Compile the driver module: + + make install + + The binary will be installed as: + + /lib/modules/KERNEL VERSION/kernel/drivers/net/e1000/e1000.[k]o + + The install locations listed above are the default locations. They + might not be correct for certain Linux distributions. For more + information, see the ldistrib.txt file included in the driver tar. + +5. Install the module: + + insmod e1000 parameter=value + + Note that this command may need to be modified for kernel versions later + than 2.4, as follows: + + insmod /lib/modules/KERNEL VERSION/kernel/drivers/net/e1000/e1000.ko parameter=value + +6. Assign an IP address to the interface by entering the following, where + x is the interface number: + + ifconfig ethx IP_address + +7. Verify that the interface works. Enter the following, where IP_address + is the IP address for another machine on the same subnet as the + interface that is being tested: + + ping IP_address + + Command Line Parameters === -If the driver is built as a module, the following optional parameters are -used by entering them on the command
Re: [PATCH 00/15] Bridge update for 2.6.17
From: [EMAIL PROTECTED] Date: Mon, 13 Mar 2006 14:12:41 -0800 This patches includes previous bridge changes for 2.6.17 and new patches to enable using LLC to handle bridge STP packets. All applied, thanks a lot Stephen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] net/decnet/dn_route.c: fix inconsequent NULL checking
From: Adrian Bunk [EMAIL PROTECTED] Date: Sat, 11 Mar 2006 00:02:33 +0100 The Coverity checker noted this inconsequent NULL checking in dnrt_drop(). Since all callers ensure that NULL isn't passed, we can simply remove the check. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied, thanks Adrian. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [-mm patch] make drivers/net/tg3.c:tg3_request_irq()
From: Adrian Bunk [EMAIL PROTECTED] Date: Mon, 13 Mar 2006 22:26:02 +0100 This patch makes the needlessly global function tg3_request_irq() static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied, thanks Adrian. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] hostap_{pci,plx}.c: fix memory leaks
On Mon, Mar 13, 2006 at 11:28:41PM +0100, Adrian Bunk wrote: This patch fixes two memotry leaks spotted by the Coverity checker. Thanks. I'll make a bit different patch to resolve this and related PCI leaks in one change. I'm going through the Coverity reports for Host AP driver, so I'll include other fixes in a patch set, too. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ES-API?
On Tue, Mar 14, 2006 at 04:51:42PM +, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: Ugh... So people can find the ways to connect kernelspace event queue and asynchronous networking operations with object-oriented design patterns? It's time to me to have a step forward from stone age... yep ;-). Could you please provide a link, it would be nice to read this discussion. Here is a link to a paper describing the patern http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf Thank you, I will definitely read this paper. You may also be interested to know that boost ( http:/www.boost.org ) has been reviewing a C++ library submission that simulates async I/O through the use of user space threads. Discussion thread on boost is ASIO. As glibc does - not the best solution I think. /ikh This email has been scanned for all viruses by the MessageLabs SkyScan service. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
