- 1. in-driver QoS (score: 1)
- Author: s@xxxxxxxxxxxx>
- Date: Sun, 6 Jun 2004 21:28:47 +0300
- I'd like to discuss issue with QoS. In 802.11 network, there is TGe (or 802.11e), working group, developing QoS extensions for 802.11. This group's work is close to finish. Current draft should be ve
- /archives/netdev/2004-06/msg00148.html (8,408 bytes)
- 2. Re: in-driver QoS (score: 1)
- Author: xxxxxxxxxxxxxx>
- Date: Mon, 7 Jun 2004 16:00:11 +0200
- It already has that kind of in the form of arbitary qdiscs. The trick will be only to do all queueing in the qdisc and keep the hardware queue length as small as possible. I think today's drivers ca
- /archives/netdev/2004-06/msg00150.html (8,619 bytes)
- 3. Re: in-driver QoS (score: 1)
- Author: rzik@xxxxxxxxx>
- Date: Mon, 7 Jun 2004 23:35:04 +0300
- How could I use these multiple qdiscs? If I use existing driver framework, I have hard_start_xmit, that represent single queue. Do you have any examples how driver can access qdiscs directly? I.e. I
- /archives/netdev/2004-06/msg00170.html (9,731 bytes)
- 4. Re: in-driver QoS (score: 1)
- Author: en <ak@xxxxxxx>
- Date: Tue, 8 Jun 2004 00:59:23 +0200
- Normally it would be configured by the user tools (using tc) -Andi
- /archives/netdev/2004-06/msg00181.html (8,826 bytes)
- 5. Re: in-driver QoS (score: 1)
- Author: oshfuji@xxxxxxxxxxxxxx>
- Date: 07 Jun 2004 19:38:44 -0400
- Maybe you can explain a little more: Do these 4 queues translate to 4 DMA rings or channles on the NIC? Could you not use a tag like fwmark to select DMA to send to? Explain the packet path once it h
- /archives/netdev/2004-06/msg00186.html (9,730 bytes)
- 6. Re: in-driver QoS (score: 1)
- Author: nfred@xxxxxxxxxxxxxxxx>
- Date: Tue, 8 Jun 2004 08:41:14 +0300
- Exactly Let's put aside integrated service. For diff serv, NIC have 4 DMA queues. These 4 queues acts as 4 independent 802.11 channels with different backoff and contention window parameters. Actuall
- /archives/netdev/2004-06/msg00188.html (10,698 bytes)
- 7. Re: in-driver QoS (score: 1)
- Author: dam.Lewis@xxxxxxxxxxxx>
- Date: 08 Jun 2004 07:28:44 -0400
- Ok, Now that you explain this i dont think other people understood you when you started talking about qos. We have discussed this topic on netdev before under differnt context. So the 4 DMA queues ar
- /archives/netdev/2004-06/msg00195.html (11,084 bytes)
- 8. Re: in-driver QoS (score: 1)
- Author: h.venkatesan@xxxxxxxxx>
- Date: Tue, 8 Jun 2004 11:48:31 -0700
- 802.11e is about prioritisation of the traffic, not QoS. QoS is about bandwidth reservation and enforcement of policies, and 802.11e does none of that. Simple : Linux driver should always send traffi
- /archives/netdev/2004-06/msg00213.html (12,335 bytes)
- 9. Re: in-driver QoS (score: 1)
- Author: r <shemminger@xxxxxxxx>
- Date: Tue, 8 Jun 2004 12:52:38 -0700
- Yes, it's one component of a QoS solution. But, my point is that on it's own, it's not enough. This means that we should not see 802.11e as a complete QoS solution, and the center of the QoS universe
- /archives/netdev/2004-06/msg00218.html (12,587 bytes)
- 10. Re: in-driver QoS (score: 1)
- Author: atiev <vkondra@xxxxxxx>
- Date: 08 Jun 2004 16:55:39 -0400
- There is no mapping or exclusivity of QoS to bandwidth reservation. The most basic QoS and most popular QoS mechanisms even on Linux is just prioritization and nothing to do with bandwidth allocation
- /archives/netdev/2004-06/msg00222.html (12,610 bytes)
- 11. Re: in-driver QoS (score: 1)
- Author: urgh <fubar@xxxxxxxxxx>
- Date: Tue, 8 Jun 2004 15:01:09 -0700
- The difference is that the Linux infrastructure can do it, even if you don't do it, the 802.11e can't. Whatever, it does not matter. Nope they can't get to different wireless channel, unless you have
- /archives/netdev/2004-06/msg00226.html (16,107 bytes)
- 12. Re: in-driver QoS (score: 1)
- Author: en <jkmaline@xxxxxxxxx>
- Date: 08 Jun 2004 23:46:49 -0400
- Since Vladimir is not speaking up i am gonna take your word for it. so the only differentiation is on backoff and contention window parameters. In other words, higher prio will get opportunity to be
- /archives/netdev/2004-06/msg00229.html (15,930 bytes)
- 13. Re: in-driver QoS (score: 1)
- Author: jamal <hadi@xxxxxxxxxx>
- Date: Wed, 9 Jun 2004 08:51:40 +0300
- Correct. If you deal with bandwidth allocation, this is integrated service. Usually, diff serv used, which is just priority. BTW, in wireless QoS, bandwidth allocation present as well. Protocol is as
- /archives/netdev/2004-06/msg00230.html (13,845 bytes)
- 14. Re: in-driver QoS (score: 1)
- Author: ums <sneakums@xxxxxxxx>
- Date: 09 Jun 2004 07:20:10 -0400
- Sorry, I should have made it clear and reemphasized it a few times. I think Jean understands the issue but not its repurcassions. Will work fine if you have mostly only one priority really. Non-trivi
- /archives/netdev/2004-06/msg00238.html (11,349 bytes)
- 15. Re: in-driver QoS (score: 1)
- Author: a <felipe_alfaro@xxxxxxxxxxxxx>
- Date: Wed, 9 Jun 2004 10:40:21 -0700
- Yep. It's like a fast pass to cut the line at DisneyWorld. If all the FIFO take from the same memory pool, when one FIFO is full, it means that the memory pool is exhausted. If the memory pool is exh
- /archives/netdev/2004-06/msg00249.html (14,288 bytes)
- 16. Re: in-driver QoS (score: 1)
- Author: xxxx>
- Date: Wed, 9 Jun 2004 21:27:28 +0300
- Unfortunately, yes. BTW, what is fwmark? in 2.6.6 it is not present. Sure. I know when each DMA queue have space to accept new packets. w.r.t Tx discipline, it is really like 4 (taking into account
- /archives/netdev/2004-06/msg00251.html (11,173 bytes)
- 17. Re: in-driver QoS (score: 1)
- Author: 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>
- Date: 09 Jun 2004 21:47:54 -0400
- Is this how these things are designed? So there are no bounds defined for each FIFO? If yes, whoever designed those boards is on some really cheap crack. Fire his or her ass. If no, then please dont
- /archives/netdev/2004-06/msg00263.html (13,156 bytes)
- 18. Re: in-driver QoS (score: 1)
- Author: xxxxxxxxxxxxxx>
- Date: 09 Jun 2004 21:59:01 -0400
- Vladimir - do you have one of these cards? Jean is putting some my doubts in my mind about their designs. Do they have seperate DMA rings? As suggested earlier: - introduce id and id_state per ring.
- /archives/netdev/2004-06/msg00264.html (10,388 bytes)
- 19. Re: in-driver QoS (score: 1)
- Author: xxx>
- Date: Thu, 10 Jun 2004 11:45:37 +0900
- The name in the kernel was changed to nfmark a while ago. Though is seems to be still referenced as fwmark quite a lot in documentation. I believe its primary use is for the mark target and match in
- /archives/netdev/2004-06/msg00267.html (9,406 bytes)
- 20. Re: in-driver QoS (score: 1)
- Author: ipe Alfaro Solana <felipe_alfaro@xxxxxxxxxxxxx>
- Date: Thu, 10 Jun 2004 08:55:31 +0300
- Good question. Until I can really answer, let's say "in theory, all next generation wireless cards should have similar design". Hint: I have also mail ending by intel.com how? how to do it? I am afra
- /archives/netdev/2004-06/msg00273.html (11,028 bytes)
This search system is powered by
Namazu