RE: [PATCH] NET: Multiqueue network device support.
Hi Jamal, Here is a simple scenario (nothing here is rare of extreme case): - Busy wireless environment - FTP TX on BE queue (low priority) - Skype TX on VO queue (high priority) The channel is busy with high priority packets hence the BE packets are transmitted to the air rarely so the DMA/HW queue of the BE access category gets full and the qdisc is stopped. Now periodic VO-tagged Skype packets arrive. I would expect that they get the priority (and pass) in all stages of the stack and reach the HW ASAP and compete there on the medium with the other access categories and the other clients on the channel. Now this packet will be stuck in the qdisc and wait there until a BE packet is transmitted, which can take a long time. This is a real problem. There is also a problem with the queues that will be dedicated to TX aggregation in 11n (currently implemented) - the packets will be classified to queues by the destination MAC address and not only by the priority class, but I don't want to get into that now. I think that there are enough arguments now why the patch that started this thread is needed... Please see below some replies to your questions. Regards, Guy. jamal wrote: It could be estimated well by the host sw; but lets defer that to later in case i am clueless on something or you misunderstood something i said. It cannot be estimated well by the host SW. This is one of the main issues - we can't put it aside... I understand. Please correct me if am wrong: The only reason AC_BK packet will go out instead of AC_VO when contending in hardware is because of a statistical opportunity not the firmware intentionaly trying to allow AC_BK out i.e it is influenced by the three variables: 1) The contention window 2) the backoff timer and 3)the tx opportunity And if you look at the default IEEE parameters as in that url slide 43, the only time AC_BK will win is luck. In most scenarios BK packets will be transmitted and will win the medium against VO packets (thought, in some non-favored ratio). Heres a really dated paper before the standard was ratified: http://www.mwnl.snu.ac.kr/~schoi/publication/Conferences/02-EW.pdf Sorry, I'm really overloaded - I won't be able to review the docs you sent (really apologize for that). So essentially the test you mention changes priorities in real time. What is the purpose of this test? Is WMM expected to change its priorities in real time? The WMM parameters of the AC are set and controlled by the network/BSS (access point) administrator and can be used in anyway. There are the default parameters but they can be changed. Regards, Guy. - 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: Multiqueue network device support.
Patrick McHardy wrote: jamal wrote: Sure - but what is wrong with that? Nothing, this was just to illustrate why I disagree with the assumption that the packet has hit the wire. On second thought I do agree with your assumption for the single HW queue case, at the point we hand the packet to the HW the packet order is determined and is unchangeable. But this is not the case if the hardware includes its own scheduler. The qdisc is simply not fully in charge anymore. For WiFi devices the HW often implements the scheduling, especially when QoS (WMM/11e/11n) is implemented. There are few traffic queues defined by the specs and the selection of the next queue to transmit a packet from, is determined in real time, just when there is a tx opportunity. This cannot be predicted in advance since it depends on the medium usage of other stations. Hence, to make it possible for wireless devices to use the qdisc mechanism properly, the HW queues should _ALL_ be non-empty at all times, whenever data is available in the upper layers. Or in other words, the upper layers should not block a specific queue because of the usage of any other queue. Your basic assumption seems to be that the qdisc is still in charge of when packets get sent. This isn't the case if there is another scheduler after the qdisc and there is contention in the second queue. Which is often the case in wireless devices - transmission scheduling is done in HW. - 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: Multiqueue network device support.
Some more details inside regarding wireless QoS. jamal wrote: On Mon, 2007-11-06 at 17:30 +0300, Cohen, Guy wrote: For WiFi devices the HW often implements the scheduling, especially when QoS (WMM/11e/11n) is implemented. There are few traffic queues defined by the specs and the selection of the next queue to transmit a packet from, is determined in real time, just when there is a tx opportunity. This cannot be predicted in advance since it depends on the medium usage of other stations. WMM is a strict prio mechanism. The parametrization very much favors the high prio packets when the tx opportunity to send shows up. Sorry, but this not as simple as you describe it. WMM is much more complicated. WMM defines the HW queues as virtually multiple clients that compete on the medium access individually. Each implements a contention-based medium access. The Access Point publishes to the clients the medium access parameters (e.g. back off parameters) that are different for each access category (virtual client). There is _not_ a strict priority assigned to each access category. The behavior of each access category totally depends on the medium usage of other clients and is totally different for each access category. This cannot be predicated at the host SW. Hence, to make it possible for wireless devices to use the qdisc mechanism properly, the HW queues should _ALL_ be non-empty at all times, whenever data is available in the upper layers. agreed. Or in other words, the upper layers should not block a specific queue because of the usage of any other queue. This is where we are going to disagree. There is no way the stack will send the driver packets which are low prio if there are some which are high prio. There is therefore, on contention between low and high prio, no way for low prio packets to obstruct the high prio packets; And this is not the right behavior for a WLAN stack. QoS in WLAN doesn't favor strictly one access category over another, but defines some softer and smarter prioritization. This is implemented in the HW/Firmware. I just think that providing a per-queue controls (start/stop) will allow WLAN drivers/Firmware/HW to do that while still using qdisc (and it will work properly even when one queue is full and others are empty). however, it is feasible that high prio packets will obstruct low prio packets (which is fine). No this is _not_ fine. Just to emphasize again, WMM doesn't define priority in the way it is implemented in airplane boarding (Pilots first, Business passengers next, couch passengers at the end), but more like _distributed_ weights prioritization (between all the multiple queues of all the clients on the channel). As a side note, in one of the WFA WMM certification tests, the AP changes the medium access parameters of the access categories in a way that favors a lower access category. This is something very soft that cannot be reflected in any intuitive way in the host SW. cheers, jamal - 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
