Re: [PATCH 01/10] Preparatory refactoring part 1.

2007-10-01 Thread Patrick McHardy
Corey Hickey wrote: Make a new function sfq_q_enqueue() that operates directly on the queue data. This will be useful for implementing sfq_change() in a later patch. A pleasant side-effect is reducing most of the duplicate code in sfq_enqueue() and sfq_requeue(). Similarly, make a new

Re: [PATCH 01/10] Preparatory refactoring part 1.

2007-10-01 Thread Corey Hickey
Patrick McHardy wrote: Corey Hickey wrote: Make a new function sfq_q_enqueue() that operates directly on the queue data. This will be useful for implementing sfq_change() in a later patch. A pleasant side-effect is reducing most of the duplicate code in sfq_enqueue() and sfq_requeue().

Re: [PATCH 01/10] Preparatory refactoring part 1.

2007-10-01 Thread Patrick McHardy
Corey Hickey wrote: Patrick McHardy wrote: -sch-qstats.drops++; A line in the changelog explaining that this was increased twice would have been nice. Certainly; I think I didn't realize, when you originally pointed out the duplicate incrementing, that it was a bug in the original

[PATCH 01/10] Preparatory refactoring part 1.

2007-09-28 Thread Corey Hickey
Make a new function sfq_q_enqueue() that operates directly on the queue data. This will be useful for implementing sfq_change() in a later patch. A pleasant side-effect is reducing most of the duplicate code in sfq_enqueue() and sfq_requeue(). Similarly, make a new function sfq_q_dequeue().

[PATCH 01/10] Preparatory refactoring part 1.

2007-08-25 Thread Corey Hickey
Make a new function sfq_q_enqueue() that operates directly on the queue data. This will be useful for implementing sfq_change() in a later patch. A pleasant side-effect is reducing most of the duplicate code in sfq_enqueue() and sfq_requeue(). Similarly, make a new function sfq_q_dequeue().