Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*in\-driver\s+QoS\s*$/: 48 ]

Total 48 documents matching your query.

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