Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*SFQ\:\s+Reordering\?\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*SFQ\:\s+Reordering\?\s*$/: 22 ]

Total 22 documents matching your query.

1. SFQ: Reordering? (score: 1): Author: <tgraf@xxxxxxx>; Date: Fri, 6 May 2005 16:53:51 -0500; I was looking through sch_sfq.c. From what I could make out, if the perturbation period is non-zero (say Xseconds), then ever X seconds, sfq_perturbation() is invoked. This changes the perturbation; /archives/netdev/2005-05/msg00326.html (8,620 bytes)
2. Re: SFQ: Reordering? (score: 1): Author: mjt@xxxxxxxxxx>; Date: Sat, 07 May 2005 00:07:42 +0200; I think we should rehash. Can you send a patch? Regards Patrick; /archives/netdev/2005-05/msg00328.html (8,888 bytes)
3. Re: SFQ: Reordering? (score: 1): Author: esan@xxxxxxxxx>; Date: Sat, 07 May 2005 00:46:28 +0200; Hmm wait, this is not so easy. We can't rehash by going over the buckets one by one. If we do so and we have a new clash of two flows previously contained in different buckets the packets will afterw; /archives/netdev/2005-05/msg00334.html (8,976 bytes)
4. Re: SFQ: Reordering? (score: 1): Author: bunk@xxxxxxxxx>; Date: Sat, 7 May 2005 01:02:03 +0200; * Patrick McHardy <427BF3C4.1030105@xxxxxxxxx> 2005-05-07 00:46 We can maintain a second hash table and switch a pointer over to the new table but keep on dequeueing from the old one until it is empt; /archives/netdev/2005-05/msg00336.html (8,916 bytes)
5. Re: SFQ: Reordering? (score: 1): Author: bunk@xxxxxxxxx>; Date: Sat, 07 May 2005 01:19:14 +0200; This also introduces unfairness. Packets of a flow could be only in the new table while we're still working on the active table. A proper solution to avoid reordering shouldn't be optional IMO, pertu; /archives/netdev/2005-05/msg00339.html (8,896 bytes)
6. Re: SFQ: Reordering? (score: 1): Author: xx>; Date: Sat, 7 May 2005 02:58:51 +0200; * Patrick McHardy <427BFB72.7080407@xxxxxxxxx> 2005-05-07 01:19 Yes, that's true but we can't reach perfect fairness anyway. What is your primary goal? No reordering inside flows while staying as fai; /archives/netdev/2005-05/msg00345.html (9,370 bytes)
7. Re: SFQ: Reordering? (score: 1): Author: xx>; Date: Sat, 07 May 2005 03:28:35 +0200; You stated my goal precisely :) I know many people set the interval to too low values, but because of the tight limits, it shouldn't be very expensive anyways. Table switching OTOH would introduce fr; /archives/netdev/2005-05/msg00346.html (10,086 bytes)
8. Re: SFQ: Reordering? (score: 1): Author: xx>; Date: Sun, 8 May 2005 13:51:00 +0200; * Patrick McHardy <427C19C3.5030304@xxxxxxxxx> 2005-05-07 03:28 I think you are right on this so forget about my thought. Maybe as an additional input it might be worth mentioning that I have patches; /archives/netdev/2005-05/msg00368.html (9,493 bytes)
9. Re: SFQ: Reordering? (score: 1): Author: trick McHardy <kaber@xxxxxxxxx>; Date: Sun, 08 May 2005 18:03:19 +0200; Actually I was beginning to think you're right about having this feature optional. Paul McKenney's paper on SFQ states multiple times that perturbation can cause reordering if implemented the easy wa; /archives/netdev/2005-05/msg00373.html (10,752 bytes)
10. Re: SFQ: Reordering? (score: 1): Author: xxxxxx>; Date: Sun, 8 May 2005 20:33:10 +0200; * Patrick McHardy <427E3847.3050709@xxxxxxxxx> 2005-05-08 18:03 Indeed, well I think it depends on the perturbation interval, complexity and cost of the hashing function and the average queue length; /archives/netdev/2005-05/msg00375.html (10,288 bytes)
11. Re: SFQ: Reordering? (score: 1): Author: . Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 10 May 2005 00:14:47 +0100; Patrick McHardy wrote: It would be interesting to see this in real-life, when a single flow is hashed to multiple buckets (it can be even more than two) and each bucket has some packets queued, the r; /archives/netdev/2005-05/msg00388.html (9,431 bytes)
12. SFQ: Reordering? (score: 1): Author: Asim Shankar <asimshankar@xxxxxxxxx>; Date: Fri, 6 May 2005 16:53:51 -0500; Hi, I was looking through sch_sfq.c. From what I could make out, if the perturbation period is non-zero (say Xseconds), then ever X seconds, sfq_perturbation() is invoked. This changes the perturbati; /archives/netdev/2005-05/msg01615.html (8,620 bytes)
13. Re: SFQ: Reordering? (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Sat, 07 May 2005 00:07:42 +0200; I think we should rehash. Can you send a patch? Regards Patrick; /archives/netdev/2005-05/msg01617.html (8,956 bytes)
14. Re: SFQ: Reordering? (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Sat, 07 May 2005 00:46:28 +0200; Hmm wait, this is not so easy. We can't rehash by going over the buckets one by one. If we do so and we have a new clash of two flows previously contained in different buckets the packets will afterw; /archives/netdev/2005-05/msg01623.html (9,050 bytes)
15. Re: SFQ: Reordering? (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Sat, 7 May 2005 01:02:03 +0200; * Patrick McHardy <427BF3C4.1030105@xxxxxxxxx> 2005-05-07 00:46 We can maintain a second hash table and switch a pointer over to the new table but keep on dequeueing from the old one until it is empt; /archives/netdev/2005-05/msg01625.html (9,018 bytes)
16. Re: SFQ: Reordering? (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Sat, 07 May 2005 01:19:14 +0200; This also introduces unfairness. Packets of a flow could be only in the new table while we're still working on the active table. A proper solution to avoid reordering shouldn't be optional IMO, pertu; /archives/netdev/2005-05/msg01628.html (9,034 bytes)
17. Re: SFQ: Reordering? (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Sat, 7 May 2005 02:58:51 +0200; * Patrick McHardy <427BFB72.7080407@xxxxxxxxx> 2005-05-07 01:19 Yes, that's true but we can't reach perfect fairness anyway. What is your primary goal? No reordering inside flows while staying as fai; /archives/netdev/2005-05/msg01634.html (9,526 bytes)
18. Re: SFQ: Reordering? (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Sat, 07 May 2005 03:28:35 +0200; You stated my goal precisely :) I know many people set the interval to too low values, but because of the tight limits, it shouldn't be very expensive anyways. Table switching OTOH would introduce fr; /archives/netdev/2005-05/msg01635.html (10,278 bytes)
19. Re: SFQ: Reordering? (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Sun, 8 May 2005 13:51:00 +0200; * Patrick McHardy <427C19C3.5030304@xxxxxxxxx> 2005-05-07 03:28 I think you are right on this so forget about my thought. Maybe as an additional input it might be worth mentioning that I have patches; /archives/netdev/2005-05/msg01657.html (9,703 bytes)
20. Re: SFQ: Reordering? (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Sun, 08 May 2005 18:03:19 +0200; Actually I was beginning to think you're right about having this feature optional. Paul McKenney's paper on SFQ states multiple times that perturbation can cause reordering if implemented the easy wa; /archives/netdev/2005-05/msg01662.html (11,013 bytes)

Current List: 1 - 20
Page: [1] [2]