Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Wed, Nov 01, 2006 at 10:31:19AM -0800, James Ketrenos wrote: The only merge requirement should be that merging d80211 doesn't break existing in-tree wireless drivers. We have that today -- you can have both stacks in the tree and running in parallel. With that, we have the ability to migrate over time. The other 'merge requirements' are functionally irrelevant. We know the d80211 stack is where wireless on Linux is going -- the sooner steps are taken to get that stack out to the masses the faster it can be adopted and improved. We had that discussion offline last week, but let's repeat it here for the general public. The most important merge requirement is to not break userspace. That means proper support of WE (hopefully via cfg80211), and a single ethX network device. The second most important is proper smp support, or good code quality in general. We can't afford to merge buggy code. Third most important is to make sure it's a full replacment for the current ieee80211 code - for the softmac cards that's mostly trivial, but the half-hard mac old intel cards are hard. That's where intel comes into play because you support that hardware _and_ are pushing for d80211. That makes your team pretty much volunteer to fix that up in my eyes. - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006 12:16:57 + Christoph Hellwig [EMAIL PROTECTED] wrote: The most important merge requirement is to not break userspace. That means proper support of WE (hopefully via cfg80211), and a single ethX network device. Sounds reasonable. Though: - I don't think ethX is the appropriate name. It's not an ethernet device and many wireless drivers currently use wlanX name. I think the current wlanX name is a better choice here. - Single device is not as easy as it sounds. It would require rather invasive changes in the networking core or ugly hacks in d80211. I'm afraid this is something not achievable in a near future with current number of people working on d80211. But in general, it's doable and desirable, yes. The second most important is proper smp support, or good code quality in general. We can't afford to merge buggy code. I definitely agree here. Third most important is to make sure it's a full replacment for the current ieee80211 code - for the softmac cards that's mostly trivial, but the half-hard mac old intel cards are hard. That's where intel comes into play because you support that hardware _and_ are pushing for d80211. That makes your team pretty much volunteer to fix that up in my eyes. Let's see... Jiri -- Jiri Benc SUSE Labs - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, Nov 02, 2006 at 12:16:57PM +, Christoph Hellwig wrote: The most important merge requirement is to not break userspace. That means proper support of WE (hopefully via cfg80211), and a single ethX network device. The second most important is proper smp support, or good code quality in general. We can't afford to merge buggy code. Third most important is to make sure it's a full replacment for the current ieee80211 code - for the softmac cards that's mostly trivial, but the half-hard mac old intel cards are hard. That's where intel comes into play because you support that hardware _and_ are pushing for d80211. That makes your team pretty much volunteer to fix that up in my eyes. +1 This aligns very well with my position. John -- John W. Linville [EMAIL PROTECTED] - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, Nov 02, 2006 at 03:05:50PM +0100, Jiri Benc wrote: On Thu, 2 Nov 2006 12:16:57 + Christoph Hellwig [EMAIL PROTECTED] wrote: The most important merge requirement is to not break userspace. That means proper support of WE (hopefully via cfg80211), and a single ethX network device. Sounds reasonable. Though: - I don't think ethX is the appropriate name. It's not an ethernet device and many wireless drivers currently use wlanX name. I think the current wlanX name is a better choice here. This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. - Single device is not as easy as it sounds. It would require rather invasive changes in the networking core or ugly hacks in d80211. I'm afraid this is something not achievable in a near future with current number of people working on d80211. But in general, it's doable and desirable, yes. Again, I'm not sure it's even desirable in the end. We do however need a mode in which you can configure a single ethX device with WE and it'll just work. It's entirely reasonable to only support a subset of the functionality that way (no 802.11n, no AP mode, etc) - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2006-11-02 at 15:05 +0100, Jiri Benc wrote: - Single device is not as easy as it sounds. It would require rather invasive changes in the networking core or ugly hacks in d80211. I'm afraid this is something not achievable in a near future with current number of people working on d80211. But in general, it's doable and desirable, yes. Actually, just as a note to all the others (talked to Jiri about it already), I think it's easier than thought since the code is so convoluted. The only purpose of the wmaster device appears to be to have an outgoing frame queue through the qdisc. Since we require the 802.11 qdisc to be installed at the root for all netdevices anyway, we could just as well hand the frame to it right away. I'll look into that later today. johannes - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Has anyoen ever complained about that? In any case, tools iterate all netdevs and call some wireless ioctl to check if they are wireless, or check /proc/net/wireless (which is actually bad, but ...). Besides, WE never said that names have to have certain names. What makes you think so? johannes [1] http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=36b29ff058141a712619e55184566b39ce414efd;hb=aefba081d7b7dfd1c5752f6e6e709d8b5ab80ab7;f=drivers/net/wireless/zd1201.c#l1790 - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Hi Johannes, On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Neither does hostap [2] :) Thanks, Jochen [2] http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=ed00ebb6e7f4bd255d1a1fe8bf05a6f7a5574d6e;hb=aefba081d7b7dfd1c5752f6e6e709d8b5ab80ab7;f=drivers/net/wireless/hostap/hostap_hw.c#l84 - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, Nov 02, 2006 at 03:32:34PM +0100, Johannes Berg wrote: On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Has anyoen ever complained about that? In any case, tools iterate all netdevs and call some wireless ioctl to check if they are wireless, or check /proc/net/wireless (which is actually bad, but ...). Besides, WE never said that names have to have certain names. What makes you think so? I never said the name was related to WE - in fact there are tons of out of tree drivers with different names. The important bit is that upgrading a kernel adn changing the wireless stack must not change the device name. All my scripts expect my bcm43xx card to be eth1 and not wifi0 or wlansomething. There's in fact another much worse migration prblem when we want to do wlan support correctly: the advertised frametype still is 802.3 for all wlan devices (which make the current ethX names correct in some obscure very technical way) and we need to make them raw 802.11 long-term. It will probably make sense to do both migrations at the same time and have a CONFIG_ option to force the old behaviour [1]. [1] I really hate config options affecting the abi, but this is a tough problem as we can't have a etdevice with different frametypes for the same piece of hardware. maybewe could at least make it a module option.. - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2006-11-02 at 14:45 +, Christoph Hellwig wrote: I never said the name was related to WE - in fact there are tons of out of tree drivers with different names. The important bit is that upgrading a kernel adn changing the wireless stack must not change the device name. Ah, but if that is your point then you should be arguing that the stack may not dictate the device name at all, in order to keep existing drivers able to keep whatever devicenames they were creating now... All my scripts expect my bcm43xx card to be eth1 and not wifi0 or wlansomething. But, but.. Kernel-assigned device names aren't really stable in practise, and in most distros udev will actually assign a stable name based on the mac address (which will, incidentally, apparently be ethX). Really though, I don't care about having it ethX, I rename it to whatever I want in userspace anyway. There's in fact another much worse migration prblem when we want to do wlan support correctly: the advertised frametype still is 802.3 for all wlan devices (which make the current ethX names correct in some obscure very technical way) and we need to make them raw 802.11 long-term. It will probably make sense to do both migrations at the same time and have a CONFIG_ option to force the old behaviour [1]. Making it 802.11 will probably upset dhcp, I'd think. I have no idea how to handle that, at this time. johannes - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006 14:18:15 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. That's not true. Look at hostap or zd1201, for example. Also, ethX name is not needed for WE compatibility. And because of various names used by various drivers (madwifi uses ath0, for example) config scripts don't depend on ethX name today anyway. Jiri -- Jiri Benc SUSE Labs - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006, Jiri Benc wrote: On Thu, 2 Nov 2006 14:18:15 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. That's not true. Look at hostap or zd1201, for example. Also, ethX name is not needed for WE compatibility. And because of various names used by various drivers (madwifi uses ath0, for example) config scripts don't depend on ethX name today anyway. At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
I don't believe it makes sense to change the frame type except for the master interface. The interface to an 802.11 MAC (the MAC-SAP) is very similar to the interface to an 802.3 MAC. It is a 2 address format - not 3 or 4. The master interface is an internal part of the MAC, and here 802.11 frames are essential. Simon -Original Message- From: Christoph Hellwig [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 6:46 AM To: Johannes Berg Cc: Christoph Hellwig; Jiri Benc; James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, Nov 02, 2006 at 03:32:34PM +0100, Johannes Berg wrote: On Thu, 2006-11-02 at 14:18 +, Christoph Hellwig wrote: This is not about the name that makes sense. I think using ethX names for wireless devices is utterly stupid, but it's what all current upstream drivers do, and at least for WE compat we'll have to stick to it. No, that's not true, zd1201 doesn't [1] :) Has anyoen ever complained about that? In any case, tools iterate all netdevs and call some wireless ioctl to check if they are wireless, or check /proc/net/wireless (which is actually bad, but ...). Besides, WE never said that names have to have certain names. What makes you think so? I never said the name was related to WE - in fact there are tons of out of tree drivers with different names. The important bit is that upgrading a kernel adn changing the wireless stack must not change the device name. All my scripts expect my bcm43xx card to be eth1 and not wifi0 or wlansomething. There's in fact another much worse migration prblem when we want to do wlan support correctly: the advertised frametype still is 802.3 for all wlan devices (which make the current ethX names correct in some obscure very technical way) and we need to make them raw 802.11 long-term. It will probably make sense to do both migrations at the same time and have a CONFIG_ option to force the old behaviour [1]. [1] I really hate config options affecting the abi, but this is a tough problem as we can't have a etdevice with different frametypes for the same piece of hardware. maybewe could at least make it a module option.. - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote: At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. Then your config scripts don't work with Prism and Zydas cards. Something is broken with your setup. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) Because nobody can guarantee you even the order of your Ethernet interfaces with newer kernels (e.g. your eth0 Ethernet card may become eth1 at any time) and it will become even worse with the parallel device discovery, your setup is going to explode anyway. Sorry, I can't take this as an argument. Using your argumentation, we must preserve wlan0 name because scripts of zd1201 users will break otherwise. Or - wait a moment - no no, we must preserve ath0 name because of madwifi users - and oh, we must preserve eth1 (not ethX because the scripts cannot deal with it) because of ipw users. And we must definitely ensure that card numbers won't ever change. Even if you uplug them and replug to another slots in a different order. Sorry, that cannot work. Jiri -- Jiri Benc SUSE Labs - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2006-11-02 at 19:38 +0100, Jiri Benc wrote: On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote: At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. Then your config scripts don't work with Prism and Zydas cards. Something is broken with your setup. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) Because nobody can guarantee you even the order of your Ethernet interfaces with newer kernels (e.g. your eth0 Ethernet card may become eth1 at any time) and it will become even worse with the parallel device discovery, your setup is going to explode anyway. Sorry, I can't take this as an argument. Using your argumentation, we must preserve wlan0 name because scripts of zd1201 users will break otherwise. Or - wait a moment - no no, we must preserve ath0 name because of madwifi users - and oh, we must preserve eth1 (not ethX because the scripts cannot deal with it) because of ipw users. And we must definitely ensure that card numbers won't ever change. Even if you uplug them and replug to another slots in a different order. Sorry, that cannot work. Right. Nothing should be relying on the actual device name, they should be relying on the MAC address or some other UID of the actual device. In many distros, the config scripts depend on a set name, but only _AFTER_ they have check the devices MAC address, matched that up with a MAC-devname table, and renamed the device. That's somewhat sane, but scripts cannot just rely on the device name without checking some other unique attribute of the device. Dan Jiri - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Perhaps the solution is to allow the prefix to be a kernel configuration item? Simon -Original Message- From: Jiri Benc [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 10:39 AM To: Sven-Haegar Koch Cc: Christoph Hellwig; James Ketrenos; John W. Linville; Simon Barber; Jeff Garzik; Patrick McHardy; David Kimdon; netdev@vger.kernel.org Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, 2 Nov 2006 17:09:24 +0100 (CET), Sven-Haegar Koch wrote: At least the ones used on my machines all do. (Debian Sarge, Etch and Unstable) The configfiles can be changed without problems to use any device name, but needing to edit various files just for a kernel update would inhibt me from just trying a new version until I really know I would not need to go back to the old version again. Then your config scripts don't work with Prism and Zydas cards. Something is broken with your setup. (Switching wireless from eth1 to eth2 after copying the harddisk contents to a new laptop was work enough, but at least expected with a new machine and changed hardware) Because nobody can guarantee you even the order of your Ethernet interfaces with newer kernels (e.g. your eth0 Ethernet card may become eth1 at any time) and it will become even worse with the parallel device discovery, your setup is going to explode anyway. Sorry, I can't take this as an argument. Using your argumentation, we must preserve wlan0 name because scripts of zd1201 users will break otherwise. Or - wait a moment - no no, we must preserve ath0 name because of madwifi users - and oh, we must preserve eth1 (not ethX because the scripts cannot deal with it) because of ipw users. And we must definitely ensure that card numbers won't ever change. Even if you uplug them and replug to another slots in a different order. Sorry, that cannot work. Jiri -- Jiri Benc SUSE Labs - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, 2 Nov 2006 13:27:59 -0800 Simon Barber [EMAIL PROTECTED] wrote: Perhaps the solution is to allow the prefix to be a kernel configuration item? Simon All modern distro's support device naming stuff through hotplug. Don't put effort into keeping the kernel defaults absolute. Please have Ethernet (and wireless) devices show up as eth%d. For the master device, choose something else (mac%d ?). -- Stephen Hemminger [EMAIL PROTECTED] - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On 11/2/06, Stephen Hemminger [EMAIL PROTECTED] wrote: Please have Ethernet (and wireless) devices show up as eth%d. For the master device, choose something else (mac%d ?). If ultimately we're going to make wireless devices, as John puts it, 1st class citizens by making 802.11 a full protocol we should just start sticking to a new convention. Before when we didn't have any softmac drivers in the kernel ethX made sense, with softmac this isn't so clear, but with 802.11 as a full protocol perhaps wlanX will finally make perfect sense. For the master device yes, how about mac%d as its there do 802.11 MAC management. - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Wed, 25 Oct 2006 22:15:23 -0700, Simon Barber wrote: Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) This is something I really want too. However, the biggest problem is bridging. A lot of people bridge their ethernet and wifi interfaces together. We'll need to change the bridging code to make it possible again. I would also like to see: Drivers to use register_netdev - not special ieee80211 register to register themselves I don't see a benefit in this, but well, let's consider it when there is a patch. Drivers to use a normal hard_start_xmit function - need to move 802.11 pre xmit frame processing into the qdisc dequeue function Agreed. It's not a priority, though. Get rid of gunky beacon multicast buffered frame handling - make them into normal queues like everything else (so same hard_start_xmit can be used). I'm not sure about beacons here - don't some drivers need to handle them specially? Thanks, Jiri -- Jiri Benc SUSE Labs - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Wed, Nov 01, 2006 at 11:28:05AM +0100, Jiri Benc wrote: On Wed, 25 Oct 2006 22:15:23 -0700, Simon Barber wrote: Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) This is something I really want too. I see Simon's suggestions in the category of making wireless devices 1st class citizens. I mostly agree with his suggestions, and they are on my list. Do we see these as merge requirements? I have them as a lower priority than locking analysis/fixes, cfg80211 migration, fullmac support, and driver porting. Is this agreeable? Or do we think this needs to happen before a merge to -mm? John -- John W. Linville [EMAIL PROTECTED] - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
John W. Linville wrote: On Wed, Nov 01, 2006 at 11:28:05AM +0100, Jiri Benc wrote: On Wed, 25 Oct 2006 22:15:23 -0700, Simon Barber wrote: Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) This is something I really want too. I see Simon's suggestions in the category of making wireless devices 1st class citizens. I mostly agree with his suggestions, and they are on my list. Do we see these as merge requirements? The only merge requirement should be that merging d80211 doesn't break existing in-tree wireless drivers. We have that today -- you can have both stacks in the tree and running in parallel. With that, we have the ability to migrate over time. The other 'merge requirements' are functionally irrelevant. We know the d80211 stack is where wireless on Linux is going -- the sooner steps are taken to get that stack out to the masses the faster it can be adopted and improved. The agreement to switch to d80211 was reached back in April -- its been six months and there still doesn't appear to be traction at putting in action the decisions reached at that time. If people have issues with with specific components of d80211 prior to its merging, stand up and state what they are and how not fixing them would negatively impact people that aren't using the d80211 subsystem. Don't take the above as me saying there aren't items that need to be fixed/improved in d80211 -- there is work to be done. But that shouldn't stop it from being merged w/ the EXPERIMENTAL flag set. Is this agreeable? Or do we think this needs to happen before a merge to -mm? We reached the point where we should be in -mm a long time ago as soon as both stacks could exist concurrently. d80211 should have been in Linus' tree a long time ago. 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
James Ketrenos wrote: If people have issues with with specific components of d80211 prior to its merging, stand up and state what they are and how not fixing them would negatively impact people that aren't using the d80211 subsystem. Don't take the above as me saying there aren't items that need to be fixed/improved in d80211 -- there is work to be done. But that shouldn't stop it from being merged w/ the EXPERIMENTAL flag set. We reached the point where we should be in -mm a long time ago as soon as both stacks could exist concurrently. d80211 should have been in Linus' tree a long time ago. d80211 merge stoppers: - SMP issues (lack of locking, and overlocking via use of Big Network Lock) - userspace ABI It definitely shouldn't go upstream without that stuff. Jeff - 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
d80211 merge (was Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc)
Jeff Garzik wrote: James Ketrenos wrote: If people have issues with with specific components of d80211 prior to its merging, stand up and state what they are and how not fixing them would negatively impact people that aren't using the d80211 subsystem. Don't take the above as me saying there aren't items that need to be fixed/improved in d80211 -- there is work to be done. But that shouldn't stop it from being merged w/ the EXPERIMENTAL flag set. We reached the point where we should be in -mm a long time ago as soon as both stacks could exist concurrently. d80211 should have been in Linus' tree a long time ago. d80211 merge stoppers: - SMP issues (lack of locking, and overlocking via use of Big Network Lock) So we can set BROKEN_ON_SMP on it and we're good. The entire description of EXPERIMENTAL in init/Kconfig matches perfectly what we want -- bug reports, wider exposure, and a clear articulation that the feature is unstable. - userspace ABI What's the requirement on the userspace ABI? That the existing wireless extension interface needs to work, or ? We can use the wireless extension currently to match (most of) the existing WE functionality -- at least to get the majority of wireless users up and running (for those that have cards that have d80211 drivers anyway). It definitely shouldn't go upstream without that stuff. How will merging with the existing locking problems or ABI issue negatively impact people that aren't using the d80211 subsystem anyway? If having the code there doesn't hurt anyone, why not get it out for wider adoption, exposure, and contribution? Why is there such a hesitation to merge this stack and help to accelerate the set of functionality available with wireless on Linux? 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
IEEE 802.11 in any way.
-#define CHILD_QDISC_OPS pfifo_qdisc_ops
-
static inline int WLAN_FC_IS_QOS_DATA(u16 fc)
{
return (fc 0x8C) == 0x88;
@@ -433,7 +431,7 @@ static int wme_qdiscop_init(struct Qdisc
/* create child queues */
for (i = 0; i queues; i++) {
skb_queue_head_init(q-requeued[i]);
- q-queues[i] = qdisc_create_dflt(qd-dev, CHILD_QDISC_OPS);
+ q-queues[i] = qdisc_create_dflt(qd-dev, pfifo_qdisc_ops);
if (q-queues[i] == 0) {
q-queues[i] = noop_qdisc;
printk(KERN_ERR %s child qdisc %i creation failed,
dev-name, i);
Index: wireless-dev/net/d80211/Kconfig
===
--- wireless-dev.orig/net/d80211/Kconfig
+++ wireless-dev/net/d80211/Kconfig
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select NET_SCHED
pfifo_fast is available even without CONFIG_NET_SCHED, maybe
thats a better choice to avoid unnecessary bloat.
-
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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Patrick McHardy wrote:
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This allows
removal of net/d80211/fifo_qdisc.c which isn't particularily tied to
IEEE 802.11 in any way.
-#define CHILD_QDISC_OPS pfifo_qdisc_ops
-
static inline int WLAN_FC_IS_QOS_DATA(u16 fc)
{
return (fc 0x8C) == 0x88;
@@ -433,7 +431,7 @@ static int wme_qdiscop_init(struct Qdisc
/* create child queues */
for (i = 0; i queues; i++) {
skb_queue_head_init(q-requeued[i]);
- q-queues[i] = qdisc_create_dflt(qd-dev, CHILD_QDISC_OPS);
+ q-queues[i] = qdisc_create_dflt(qd-dev, pfifo_qdisc_ops);
if (q-queues[i] == 0) {
q-queues[i] = noop_qdisc;
printk(KERN_ERR %s child qdisc %i creation failed,
dev-name, i);
Index: wireless-dev/net/d80211/Kconfig
===
--- wireless-dev.orig/net/d80211/Kconfig
+++ wireless-dev/net/d80211/Kconfig
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select NET_SCHED
pfifo_fast is available even without CONFIG_NET_SCHED, maybe
thats a better choice to avoid unnecessary bloat.
BTW, I noticed a few bugs while looking at the qdisc handling in
wireless-dev:
- wme_qdiscop_enqueue doesn't increment q.qlen for packets queued
to q-requeued[], which might cause upper layer code to stop
dequeueing if q.qlen reaches zero.
- classify_1d doesn't care about tc_classify return values.
tc_classify may decide to steal packets, drop them, etc. In case
of stolen packets this causes use-after-free, otherwise just
malfunctions.
- classify_1d returns res.class if it is != -1, which can never happen
(except with an empty classifier list because of the explicit
initialization, but you should check the return code) since -get()
and -bind_tcf() both return 0 for invalid classes and the classid
otherwise. There's also an off-by-one, classids start at one, so it
should return res.class - 1 (or better res.classid - 1, which is
meant to be a numerical identifier).
- wme_discop_destroy leaks classifier module references and memory
when destroying classifiers, it should use tcf_destroy()
Considering that it is possibly and may be desirable to attach a
different qdisc than the built-in multiband qdisc, it might also
make sense to split the 80211 specific classification in a seperate
classifier module to allow simple classification of management traffic
with other qdiscs.
-
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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Pfifo_fast does not make sense because the 802.11 qdisc already
categorizes the frames based on DSCP. The better thing would be to
extract the pfifo qdisc so that it does not require NET_SCHED, but this
is more work.
Simon
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Patrick McHardy
Sent: Wednesday, October 25, 2006 4:29 PM
To: David Kimdon
Cc: netdev@vger.kernel.org; John W. Linville; Jiri Benc
Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than
d80211-specific qdisc
David Kimdon wrote:
wme.c needs a generic fifo qdisc for each hardware queue. Switch
wme.c to use the generic fifo qdisc in net/sched/sch_fifo.c. This
allows removal of net/d80211/fifo_qdisc.c which isn't particularily
tied to IEEE 802.11 in any way.
-#define CHILD_QDISC_OPS pfifo_qdisc_ops
-
static inline int WLAN_FC_IS_QOS_DATA(u16 fc) {
return (fc 0x8C) == 0x88;
@@ -433,7 +431,7 @@ static int wme_qdiscop_init(struct Qdisc
/* create child queues */
for (i = 0; i queues; i++) {
skb_queue_head_init(q-requeued[i]);
- q-queues[i] = qdisc_create_dflt(qd-dev,
CHILD_QDISC_OPS);
+ q-queues[i] = qdisc_create_dflt(qd-dev,
pfifo_qdisc_ops);
if (q-queues[i] == 0) {
q-queues[i] = noop_qdisc;
printk(KERN_ERR %s child qdisc %i creation
failed, dev-name,
i);
Index: wireless-dev/net/d80211/Kconfig
===
--- wireless-dev.orig/net/d80211/Kconfig
+++ wireless-dev/net/d80211/Kconfig
@@ -3,6 +3,7 @@ config D80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select NET_SCHED
pfifo_fast is available even without CONFIG_NET_SCHED, maybe thats a
better choice to avoid unnecessary bloat.
-
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
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Simon Barber wrote: Pfifo_fast does not make sense because the 802.11 qdisc already categorizes the frames based on DSCP. The better thing would be to extract the pfifo qdisc so that it does not require NET_SCHED, but this is more work. It wouldn't really hurt though since all frames queued to a band already have the same priority, so pfifo_fast behaves similar to fifo. BTW, is there a specific reason for using DSCP? Normally Linux uses rt_tos2priority and prio2band for determining a priority for IP packets. I don't want to argue that one is better than the other, but there is some value in keeping things consistent .. - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Simon Barber wrote: Pfifo_fast does not make sense because the 802.11 qdisc already categorizes the frames based on DSCP. The better thing would be to extract the pfifo qdisc so that it does not require NET_SCHED, but this is more work. This patch should be enough to use it without NET_SCHED. You could of course also allow modular build. diff --git a/net/d80211/Kconfig b/net/d80211/Kconfig index 0f07d41..2cb79c1 100644 --- a/net/d80211/Kconfig +++ b/net/d80211/Kconfig @@ -3,6 +3,7 @@ config D80211 select CRYPTO select CRYPTO_ARC4 select CRYPTO_AES + select NET_SCH_FIFO ---help--- This option enables the hardware independent IEEE 802.11 networking stack. diff --git a/net/sched/Kconfig b/net/sched/Kconfig index 8298ea9..1d8b0dc 100644 --- a/net/sched/Kconfig +++ b/net/sched/Kconfig @@ -40,6 +40,10 @@ config NET_SCHED The available schedulers are listed in the following questions; you can say Y to as many as you like. If unsure, say N now. +config NET_SCH_FIFO + bool + default y if NET_SCHED=y + if NET_SCHED choice diff --git a/net/sched/Makefile b/net/sched/Makefile index 0f06aec..ff2d6e5 100644 --- a/net/sched/Makefile +++ b/net/sched/Makefile @@ -4,7 +4,7 @@ # obj-y := sch_generic.o -obj-$(CONFIG_NET_SCHED)+= sch_api.o sch_fifo.o sch_blackhole.o +obj-$(CONFIG_NET_SCHED)+= sch_api.o sch_blackhole.o obj-$(CONFIG_NET_CLS) += cls_api.o obj-$(CONFIG_NET_CLS_ACT) += act_api.o obj-$(CONFIG_NET_ACT_POLICE) += act_police.o @@ -14,6 +14,7 @@ obj-$(CONFIG_NET_ACT_MIRRED) += act_mirr obj-$(CONFIG_NET_ACT_IPT) += act_ipt.o obj-$(CONFIG_NET_ACT_PEDIT)+= act_pedit.o obj-$(CONFIG_NET_ACT_SIMP) += act_simple.o +obj-$(CONFIG_NET_SCH_FIFO) += sch_fifo.o obj-$(CONFIG_NET_SCH_CBQ) += sch_cbq.o obj-$(CONFIG_NET_SCH_HTB) += sch_htb.o obj-$(CONFIG_NET_SCH_HPFQ) += sch_hpfq.o
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Thu, Oct 26, 2006 at 03:21:10AM +0200, Patrick McHardy wrote: Considering that it is possibly and may be desirable to attach a different qdisc than the built-in multiband qdisc, it might also make sense to split the 80211 specific classification in a seperate classifier module to allow simple classification of management traffic with other qdiscs. I've been telling the wireless people this for ages... Jeff - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
The Wi-Fi alliance's test plans for their WMM specification are written assuming you use certain specific DSCP values. Since WMM is the only QoS mechanism that is widely used with 802.11 I followed the WMM values in the default 802.11 qdisc implementation. Most windows 802.11 drivers do the same thing. Simon -Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 6:50 PM To: Simon Barber Cc: David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc Simon Barber wrote: Pfifo_fast does not make sense because the 802.11 qdisc already categorizes the frames based on DSCP. The better thing would be to extract the pfifo qdisc so that it does not require NET_SCHED, but this is more work. It wouldn't really hurt though since all frames queued to a band already have the same priority, so pfifo_fast behaves similar to fifo. BTW, is there a specific reason for using DSCP? Normally Linux uses rt_tos2priority and prio2band for determining a priority for IP packets. I don't want to argue that one is better than the other, but there is some value in keeping things consistent .. - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Doing this will slow down the qdisc - it does already run an external classifier first if you install one. On typical laptops performance is not a problem, but one common usage does have problems. The performance of a wireless home gateway based on a simple linux kernel configuration (NAT, iptables, bridging) is significantly slower than a VxWorks based one. With the arrival of 802.11n improving the performance of the stack is very important. The VxWorks solution may be less flexible in terms of what it can do, but it will allow the full 802.11n bandwidth to be achieved on slower embedded CPUs than Linux does. How to improve the linux kernel networking to improve it's efficiency here is a hard problem. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik Sent: Wednesday, October 25, 2006 7:39 PM To: Patrick McHardy Cc: David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Thu, Oct 26, 2006 at 03:21:10AM +0200, Patrick McHardy wrote: Considering that it is possibly and may be desirable to attach a different qdisc than the built-in multiband qdisc, it might also make sense to split the 80211 specific classification in a seperate classifier module to allow simple classification of management traffic with other qdiscs. I've been telling the wireless people this for ages... Jeff - 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
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Wed, Oct 25, 2006 at 08:37:04PM -0700, Simon Barber wrote: Doing this will slow down the qdisc - it does already run an external classifier first if you install one. On typical laptops performance is not a problem, but one common usage does have problems. The performance of a wireless home gateway based on a simple linux kernel configuration (NAT, iptables, bridging) is significantly slower than a VxWorks based one. With the arrival of 802.11n improving the performance of the stack is very important. The VxWorks solution may be less flexible in terms of what it can do, but it will allow the full 802.11n bandwidth to be achieved on slower embedded CPUs than Linux does. How to improve the linux kernel networking to improve it's efficiency here is a hard problem. First do it right, then tune performance. If you aren't doing it right, then who cares about VxWorks. We also need 802.11 to register as a real protocol, rather than faking ethernet. David Miller did an example stub: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2 Jeff - 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] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) I would also like to see: Drivers to use register_netdev - not special ieee80211 register to register themselves Drivers to use a normal hard_start_xmit function - need to move 802.11 pre xmit frame processing into the qdisc dequeue function Get rid of gunky beacon multicast buffered frame handling - make them into normal queues like everything else (so same hard_start_xmit can be used). Simon -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 10:04 PM To: Simon Barber Cc: Patrick McHardy; David Kimdon; netdev@vger.kernel.org; John W. Linville; Jiri Benc Subject: Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc On Wed, Oct 25, 2006 at 08:37:04PM -0700, Simon Barber wrote: Doing this will slow down the qdisc - it does already run an external classifier first if you install one. On typical laptops performance is not a problem, but one common usage does have problems. The performance of a wireless home gateway based on a simple linux kernel configuration (NAT, iptables, bridging) is significantly slower than a VxWorks based one. With the arrival of 802.11n improving the performance of the stack is very important. The VxWorks solution may be less flexible in terms of what it can do, but it will allow the full 802.11n bandwidth to be achieved on slower embedded CPUs than Linux does. How to improve the linux kernel networking to improve it's efficiency here is a hard problem. First do it right, then tune performance. If you aren't doing it right, then who cares about VxWorks. We also need 802.11 to register as a real protocol, rather than faking ethernet. David Miller did an example stub: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/dave m-p80211.tar.bz2 Jeff - 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
